









mmmM 











DUDLEY KNOX LIBRARY 
NAVAL POSTGRADUATE SCHOOL 
MONTEREY, CALIFORNIA 93043 



NAVAL POSTGRADUATE SCHOOL 

Monterey, California 




THESIS 



THE DESIGN AND IMPLEMENTATION OF 
A RELATIONAL INTERFACE FOR 
THE MULTI -LINGUAL DATABASE SYSTEM 

by 

Gary R. Kloepping 
and 

John F. Mack 
June 1985 



Thesis Advisor: David K. Hsiao 



roved for public release; distribution is unlimited 



T2228?3 




I 





SECURITY classification QF THIS PAGE rWh*rt D^tm Snfrm<f) 



REPORT DOCUMENTATION PAGE 


READ INSTRUCTIONS 
BEFORE COMPLETING FORM 


1. REPORT NUMBER 


2. GOVT ACCESSION NO. 


3. RECIPIENT'S CATALOG NUMBER 


4, TITLE 

The Design and Implementation 
of A Relational Interface For the Multi- 
Lingual Database System 


5. TYPE OF REPORT & PERIOD COVERED 

Mas ter ' s Thesis 
. June 1985 


6. PERFORMING ORG. REPORT NUMBER 


7. AUTHOR('iJ 

Gary R. Kloepping and 
John F . Mack 


8. contract or grant NUMBERf*) 


9. PERFORMING ORGANI 2ATION NAME AND ADDRESS 

Naval Postgraduate School 
Monterey, CA 93943 


10. PROGRAM ELEMENT. PROJECT, TASK 
AREA 4 WORK UNIT NUMBERS 


It. CDNTg^OLLING OFFICE NAME and ADDRESS 

Naval Postgraduate School 
Monterey, CA 93943 


12. REPORT OATS 

June 1985 


13. NUM0ER OF PAGES 

1 84 


14. monitoring agency name & ADDRESS^// diffarant from Controlling Offica) 


IS. SECURITY CLASS, (ot thi, r.portj 

Unclassified 


15«. DECLASSIFICATION/ DOWNGRADING 

SCHEDULE i 

! 



16. OISTRiauTlON ST ATEMEN T ('o/ fh/a R#pofO 



Approved for public release; distribution is unlimited 



17. OlSTRlSUTlON STATEMENT (of tho mbatract antarad /n Block 20, It diffarant from Raport) 



18. supplementary NOTES 



19. KEY WORDS (Continua on ravarsa alda if nacmaaary and idantify by block numbar) 

Multi-Lingual Database System; Multi -Backend Data Base System; 
Relational Database; Relational/SQL Interface 



20. abstract (Continua on ravaraa alda If nacaamary and Idantify by block numbar) 

Traditionally, the design and implementation of a conventional 
database system begins with the choice of a data model followed 
by the specification of a model-based data language.- Thus, the 
database system is restricted to a single data model and a 
specific data language. An alternative to this traditional 
approach to database-system development is the multi-lingual data- 
base system (MLDS) . This alternative approach enables the user 

f Con t in uedl 

1473 EDITION OF 1 NOV 65 IS OBSOLETE 
5 N 0102- LF-OU- 6601 



DO 

1 JAN 73 



SECURITY CLASSIFICATION OF THIS PACE (Whan Data Sntarad) 



security classification of this page fWh«n Dmim Ent 9 T 0 <O 



ABSTRACT (Continued) 

to access and manage a large collection o£ databases via 
several data models and their corresponding data language with- 
out the aforementioned restriction. 

In this thesis, we present the specification and implementation 
of a relational/SQL language calls into attribute-based date 
language (ABDL) requests. We describe the software engineering 
aspects of our implementation and an overview of the four 
modules which comprise our relational/SQL language interface. 



■ ^ 
% 



S'N 0102* LF- 014- 6601 



SECURITY CLASSIFICATION OF THIS PAGEfirh^n Dstm Entmrmd) 

2 



Approved -for Public Release, Distribution Unlimited. 



The Design and Implementation of a 
Relational Interface for the 
Multi— Lingual Database System 

by 

Sary R. j^loepping 
Captain, United States Army 
B.S. , United States Military Academy, 1976 

and’ 

John F. Mack J 
Captain, United States Army 
B.S. , United States Military Academy, 197S 

Submitted in partial fulfillment of the 
requirements for the degree of 

MAST€R-OF SCIENCE IN COMPUTER SCIENCE 

from the 

NAVAL POSTGRADUATE SCHOOL 
June 1985 



ABSTRACT 



<■ / 



Traditionally, the design and implementation of a 
conventional database system begins with the choice of a 
data model followed by the specification of a model— based 

i 

data language. Thus, the database system is restricted to a 
single data model and a specific data language. An 
alternative to this traditional approach to database— system 
development is the mul ti -1 i ngual database system (MLDS) . 
This alternative approach enables the user to access and 
manage a large collection of databases via several data 
models and their correspond! ng data languages without the 
af orementi oned re^tri cti on. 

In this thesis we present the specification and 
implementation of a rel ati onal /SQL language interface for 
the MLDS- Speci f i cal 1 y , we present the speci f i cati on and 
implementation of an interface which translates SQL language 
calls into attri bute— based data language (ABDL) requests. 
We describe the software engineering aspects of our 
implementation and an overview of the four modules which 
comprise our rel ati onal /SQL language interface. 



TABLE OF CONTENTS 



I. INTRODUCTION 12 

A. MOTIVATION 12 

B. THE MULT I -LINGUAL DATABASE SYSTEM 15 

C. THE KERNEL DATA MODEL AND LANGUAGE 17 

D. THE MULT I -BACKEND DATABASE SYSTEM 18 

E. THESIS OVERVIEW \ . 20 



II. SOFTWARE ENGINEERING OF A LANGUAGE 
INTERFACE 



A. DESIGN GOALS 22 

B. AN APPROACH TO THE DESIGN 23 

1. The Implementation Strategy 23 

2. Techniques for Software 

Development 24 

3. Characteristics of the Interface 

Software 26 

C. A CRITIQUE OF THE DESIGN 28 

D. THE DATA STRUCTURE 30 

1. Data Shared by All Users 30 

2. Data Specific to Each User 34 

E. THE ORGANIZATION OF THE NEXT FOUR 

CHAPTERS 37 

III. THE LANGUAGE INTERFACE LAYER (LID 38 

A. THE LIL PROCESS 39 

1. Important Data Structures ' 39 



2. Procedures and Functions 41 

a. Initialization 41 

b- Creating the Transaction 

List 42 

c- Accessing the Transaction 

Li St 43 

(1) Sending Creates to the 

KMS ! . 44 

(2) Sending Quer'ies to the 

KMS 44 

. ,,d. .Calling the KC 1 45 

e. Wrapping— up 45 

B. SHORTCOMINGS 46 

IV. THE KERNEL' MAPPING SYSTEM (KMS) 47 

A. AN OVERVIEW OF THE MAPPING PROCESS 47 

1. The KMS Parser / Translator 47 

2- The KMS Data Structures 49 

B. FACILITIES PROVIDED BY THE 

IMPLEMENTATION 52 

1. Database De-finitions 52 

2. Database Manipulations 54 

a. The SQL SELECT to the ABDL 

RETRIEVE 55 

b. The SQL INSERT to the ABDL 

INSERT 58 



6 



c. The SQL UPDATE to the ABDL 

UPDATE 59 

d. From the SQL DELETE to the 

ABDL DELETE: An Example 59 

C. FACILITIES NOT PROVIDED BY THE 

IMPLEMENTATION 65 

1. Inter-facing Users 66 

2. Updating Multiple Attributes . 66 

3» Retrieving Qualified Groups 67 

4. Retrieving Computed Values 67 

5^ .Eliminating Duplicates 68 

6. Retrieval Using UNION 68 

V. THE KERNEL CONTROLLER 69 

A. AN OVERVIEW OF THE KC DATA 

STRUCTURES 71 

B. KC PROCEDURES AND FUNCTIONS 77 

1. The Kernel ^Control 1 er 77 

2. The Creation of a New Database 78 

3. Insert, Delete, Update and 

Retri eve— Common Requests 78 

4. Retrieve Requests 79 

a. The N_con juncti on 

Procedure 82 

b. The Procedures 
Not_i n_con juncti on 

and One_con juncti on . 85 



7 



VI. THE KERNEL FORMATTING SYSTEM (KFS) 89 

A. THE KFS PROCESS . . 90 

1. Overview o-f the KFS Data 

Structures 91 

2. KFS Procedures and Functions 95 

a. Initializing 95 

b. Filling the Table Headings 95 

c. Creating the Table in the 

Output File 97 

d. Displaying the Table 99 

,,e. .Cleaning Up 99 

B. A LIMITATION OF THE KFS 100 

VII. CONCLUSION 101 

APPENDIX A - SCHEMATIC OF THE DATA 

STRUCTURES 104 

APPENDIX B - THE LIL PROGRAM SPECIFICATIONS 122 

APPENDIX C - THE KMS PROGRAM SPECIFICATIONS 129 

APPENDIX D - THE KC PROGRAM SPECIFICATIONS 148 

APPENDIX E - THE KFS PROGRAM SPECIFICATIONS 169 

APPENDIX F - THE SDL USERS' MANUAL 176 

A. OVERVIEW 176 

B. USING. THE SYSTEM 176 

t 

1. Processing Creates 178 

2. Processing Queries 178 

C. DATA FORMAT 180 

D. RESULTS • 181 



a 



LIST OF REFERENCES 182 

INITIAL DISTRIBUTION LIST 184 



LIST OF FIGURES 



Figure 1. The Mul ti -Lingual Database 

System 16 

Figure 2. The Mul ti —Backend Database 

System 19 

Figure 3. The dbid_node Data Structure 31 

Figure 4. The rel _dbi d_node Data 

Structure C . 31 

'Figure 5. The rel_node Data Structure 32 

Figure 6. The rattr_node Data Structure 33 

Figure 7. .The user_in-fo Data Structure 34 

Figure 8. The li_in-fo Data Structure 35 

Figure 9. The sql_in-fo Data Structure 35 

Figure 10- The tran_info Data Structure 39 

Figure 11. The rel _req_i n-f o Data 

Structure 40 

Figure 12. The rel _kms_in-f o Data 

Structure 50 

Figure 13. Additional KMS Data Structures 51 

Figure 14. The Relational Database Schema 54 

Figure 15. The sql_in-fo Data Structure 71 

Figure 16. The tran_info Data Structure 72 

Figure 17. The ab_req_in+o Data Structure 73 

Figure 13. The kc_rel_info Data Structure 74 

Figure 19. The ABDL Retrieve Generated by the 

Procedure N_con junct i on • 85 



10 



Figure 20, The ABDL Retrieve Generated by the 

Procedure Not_in_con junction 87 

Figure 21. The ABDL Retrieve Generated by the 

Procedure One_con juncti on 88 

Figure 22. The kf s_rel_inf o Data Structure 91 

Figure 23. The table_header_inf o Data 

Structure 93 

Figure 24. The tabl e_entry_inf o Data 

Structure - 94 

Figure 25. The Relational Database Schema 

. Data Structures 106 

Figure 26. The User Data Structures 109 



I. INTRODUCTION 



A- MOTIVATION 

During the past twenty years database systems have been 

designed and implemented using what we refer to as 

the traditional approach. The first^step in the traditional 

approach involves choosing a data model . Candidate data 

models include the relational data model, the hierarchical 

data model, the network data model, the ent i ty-rel at i onshi p 
■* « , ♦ 

data model, or the attr i bute-based data model to name a tew. 
The second step specifies a model-based data language, e.g., 
SQL or QUEL for the relational data model, or Daple;< for the 
entity-relationship data model. 

A number of database systems have been developed using 
this methodology. For example, there is IBM's 

Information Management System (IMS) since the sixties, 
which supports the hierarchical data model and the 
hierarchical-model-based data language. Data Language I 
(DL/I). Sperry Uni vac has introduced the DMS— 1100 in the 
early seventies, which supports the network data model and 
the network-model -based data language, CODASYL Data 
Manipulation Language (CODASYL-DML) . And more recently, 
there has been IBM's introduction of the SQL/Data System 



12 



which supports the relational model and the relational- 
model-based data language. Structured English Query 
Language (SQL). The result ot this traditional approach 
to database system development is a homogeneous database 
system that restricts the user to a single data model and a 
specific model "based data language. 

An unconventional approach to database system 
development, referred to as the< 

(MLDS) CRef. 13, alleviates; the aforementioned 
restriction. This new system affords the user the ability 
to access and manage a large collection of databases via 
several data models and their correspond! ng data languages. 
The design goals of MLDS involve developing a system 
that is accessible via a rei ati onal /SQL interface, an 
hi erarchi cal /DL/ I interface, a networ k/CODASYL 
interface, and an enti ty-rel ati onship/Dapl e>^ interface. 

There is a number of advantages in developing such a 
system. Perhaps the most practical of these involves the 
reusability of database transactions developed on an 
existing database system. In MLDS, there is no need 
for the user to convert a transaction from one data 
language to another data language. The MLDS permits the 
running of database transactions written in different data 
languages. Hence, the user does not have to perform 
either a manual or automated translation of an existing 



transaction in 



order to execute the transaction in MLDS. 



The MLDS provides the same results even if the data language 
of the transaction is originated at a different database 
system. 

A second advantage deals with the economy and 
effectiveness of hardware upgrade. Frequently, the 
hardware supporting the database system is upgraded 
because of technological advancements or system 
demand. With the traditional approach, this 'type of 
hardware upgrade has to be provided for all of the different 
database systems in use, so that all of the users can 
e>tperience system performance improvements. 'This is not 
the case in liLDS, where only the upgrade of a single 
system is necessary. In a MLDS, the benefits of a hardware 
upgrade are uniformly distributed across all users, despite 
their use of different models and data languages. 

Thirdly, a mul ti -1 i ngual database system allows users 
to explore the desirable features of the different data 
models and then use these to better support their 
applications. This is possible because MLDS supports a 
variety of databases structured in any of the well-known 
data models. 

It is apparent that there exists ample motivation to 
develop a mul t i -1 i ngual database system with many data 
model/data language interfaces. In this thesis, we are 
developing a rel ati onal /SQL language interface for the MLDS- 
We are extending the work of Macy CRef. 21 and Rollins 
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CRs'f • 3D, who have showed the feasibility of this particular 
interface in a MLDS. 

B. THE MULTI-LINGUAL DATABASE SYSTEM 

A detailed discussion of each of the components of a 
MLDS is provided in subsequent chapters. In this section we 
provide an overview of the organization of a MLDS. This 

can assist the reader in understanding how the 

different components of the MLDS are^ related. 

Figure 1 shows the system structure of a multi- 

lingual database system. The user interacts with the 
system through the 1 anouage interface layer <LIL) using a 
chosen user data mgdel^ ^U2M) to issue transactions v-jritten 
in a correspondi ng model-based user data i^DSuage ^UjDL) . 
The LIL routes the user transactions to the kernel 
lY^tem <KMS) . The KMS perf orms one of two 

possible tasks. First, the KMS transforms a UDM-based 

database definition to a database definition of the kernel, 

v-4hen the user specifies that a new database 
is to be created. When the user specifies that a UDL 
transaction is to be executed, the KMS translates the UDL 
transaction to a transaction in the kernel^ data language 
(KDL) . In the first task, the KMS forv^jards the KDM data 
definition to the kernel, controller (KC) . The KC , in turn, 
sends the KDM database definition to the kernel database 
system <KDS) . When the KDS is f i ni shed . wi th processing 
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UDM 


: L*5«r Data Model 


UDL 


; User Data Language 


LIL 


. Language Interface Layer 


KMS 


: Kernel Mapping 5^’stem 


KC 


: Kernel Controller^ 


KFS 


: Kernel Formaiung System 


KDM 


: Kernel Data Model 


KDL 


; Kernel Data Language 


KDS 


: Kernel Database Svstem 



Fi gure 



The Mul ti -Li ngual Database System, 



the KDM database de-finition, it in-forms the KC. The KC 
then notifies the user via the LIL that the database 
definition has been processed and that the loading of the 
database records may begin. In the second task, the KMS 
sends the KDL transactions to the KC. When the KC 
receives the KDL tr ansae t i ons , it forwards them to the 
KDS for execution. Upon completion, the KDS sends the 
results in KDM form back to the KC. The KC routes the 
results to the kernel^ f9C!!!§ttiD9 5 y 5 tem . The KFS 
reformats the results from KDM form to UDM form. The KFS 
then displays the results in the correct UDM form via the 
LIL. 

The four modules, LIL, KMS, KC , and KFS, are 
collectively known as the Language Interface. Four similar 
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modules are required for each other language interface of 
the MLDS. ‘ For example, there are four sets of these 
modules where one set is for the rel ati onal /SQL language 



i nter-f ace. 


one 


for 


the 


hi er arch i cal /DL/ I 


1 anguage 


interface. 


one 


for 


the 


network/CDDASYL 


1 anguage 



interface, and the last one for the entity- 
rel ati onshi p/Dapl ex language interface- However, if the 
user writes the transaction in the native mode, i . e- in KDL, 
th^re is no need of any interface- 

in our implementation of the rel ati onal /SQL 
language interface, we develop the code for the four 
modules- However, we do not integrate these modules with the 
KDS as shown in Figure 1. The Laboratory of Database 
Systems Research at the Naval Postgraduate School is in the 
process of procuring new computer equipment for the KDS. 
When the equipment is installed, the KDS will be ported over 
to the new equipment. The MLDS software will then be 
integrated with the KDS. Although not a very difficult 
undertaking, it may be time consuming. 

C. THE KERNEL DATA MODEL AND LANGUAGE 

The choice of a kernel data model and a kernel data 
language is the key decision in the development of a 
mul ti -1 i ngual database system. The overriding question, 
when making such a choice, is whether the kernel data 
model and kernel data ^ language is capable of 
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supporting the required data— model transf ormations and 
data— 1 anguage translations for the language interfaces. 

The attribute— based data model proposed by Hsiao 
CRef. 41, extended by Wong CRef. 51, and studied by Rothnie 
CRef. 61, along with the attribute— based data language 
(ABDL) , defined by Banerjee CRef. 71, have been shown to be 
acceptable candidates for the kernel data model and kernel 
data language, respectively. ^ 

^ Why is the determination of a kernel data model and 
kernel data language so important for a MLDS? No matter how 
mul ti -1 i ngual the MLDS may be, if the underlying database 
system (i.e., KDS) is slow and inefficient, then the 
interfaces may be rendered useless and untimely. Hence, 
it is important that the kernel data model and kernel 
language be supported by a hi gh— perf ormance and great- 
capacity database system. Currently, only the 
attr i bute-based data model and the attribute-based data 
language are supported by such a system. This system is 
the mul ti -backend database system (MBDS) CRef. 11. 

D. THE MULT I -BACKEND DATABASE SYSTEM 

The mul ti -backend database system (MBDS) has been 
designed to overcome the performance problems and upgrade 
issues related to the traditional approach of database 
system design. This goal is realized through the 
utilization of multiple backends connected in a parallel 
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fashion. These backends have identical hardware and 
replicated software and their own disk systems. In a 
multiple backend conf i gur ati on , there is a backend 

controller, which is responsible for supervising the 

execution of database transactions and for interfacing 
with the hosts and users. The backends perform the 

database operations with the database stored on the disk 
system of the backends. The controller and backends are 
connected by a communication bus. Users access the system 
through either the hosts or the controller directly (See 
Fi gur e 2) . 




Backend Store 2 





Comrn iimcations 
Bus 



Backend Store M 



Figure 2. The Mul ti -Backend Database System. 
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Per-formance gains are realized by increasing the number 
of backends. If the size of the database and the size 
of the responses to the transactions remain constant, then 
liBDS produces a reciprocal decrease in the response 
times for the user transactions when the number of 
backends is increased. On the other hand, if the number of 
backends is increased proporti onal ly with the increase in 
databases and responses, then MBpS produces ,in variant 
re^onse times for the same transactions. A more 
detailed discussion of MBDS can be found in CRef. 81. 

E. THESIS OVERVIEW • 

The organization of our thesis is as follows: In 
Chapter 2, we discuss the software engineering aspects of 
our implementation. This includes a discussion of our 
design approach as well as a review of the global data 
structures used for the implementation. In Chapter 3, we 
outline the functionality of the language interface 
layer. In Chapter 4, we articulate the processes 
constituting the kernel mapping system. In Chapter 5, we 
provide an overview of the kernel controller. In Chapter 

6, we describe the kernel formatting system. In Chapter 

7, We conclude the thesis. 

Appendix A cavers the data structures diagrams for the 
shared and local data. The detailed speci f i cati ons of the 
interface modules, i.e., LIL, KMS, KC, and KFS, are given in 
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Appendices B, C, D, and E, respectively. Appendix F is a 
users' manual -for the system. The speci-fi cations o-f the 
source data language, SQL, and o-f the target data 
language, ABDL, can be -found in either CRe-f. 91 or 
CRe-f. 31. 






II 



SOFTWARE ENGINEERING OF A LANGUAGE INTERFACE 



In this chapter, we discuss the various software 
engineering aspects of developing a language interface. 
First, we describe our design goals. Second, we outline 
the design approach that we took to implement the interface. 
Included in this section are C discussions of our 
impTementation strategy, our -software development 
techniques, and salient char acter i sti cs of the language 
interface software. Then, we provide a critique of our 
implementation. Fourth, we describe the data structures 
used in the interface. And finally, we provide an 
organizational description of the next four chapters. 



A. DESIGN GOALS 



We are motivated 


to implement an 


SQL 


interface for 


a 


MLDS using MBDS 


as the 


kernel 


database 


system , 


the 


attri bute— based data 


model as 


the kernel 


data 


model , 


and 



ABDL as the kernel data language. It is important to note 
that we do not propose changes to the kernel database system 
or language. Instead, our implementation resides entirely 
in the host computer. All user transactions in SQL are 
processed in the SDL interface. MBDS continues to 
receive and process requests in the syntax and semantics of 



ABDL. 



In addition, we intend to make our interface 
transparent to the user- For example, an employee in a 
corporate environment with previous experience with SQL 
could log into our system, issue an SQL request and 
receive result data in a relational format, i.e., a 
table. The employee requires no training in ABDL or MBDS 
procedures prior to utilizing the system. 

B. AN APPROACH TO THE DESIGN 

1 . The liDBiement at^gn Strategy 

There is a number of different strategies «we could 
have employed -in -the implementation of the SQL language 
interface. For example, there are the bui 1 d— i t-twi ce 
f ul 1 -prototype approach, the 1 evel -by— 1 evel top-down 
approach, the incremental development approach, and the 
advancemanshi p approach CRef. 10: pp. 41-461. We have 
predicated dur choice on minimizing the " sof tware-cr i si s'* 
as explained by Boehm CRef. 10: pp. 14-311. 

The strategy we have decided upon is the level -by- 
level top-down approach. Our choice is based on, first, 
a time constraint. The interface has to be developed 
within a specified time, speci f i cal 1 y , by the time we 
graduate. And second, this approach lends itself to the 
natural evolution of the interface- The system is 
initially thought of as- a "black box" (see Figure 1) that 
accepts SQL transactions and then returns the appropriate 



results. The "black box” is then decomposed into its 
four modules <i.e. , LIL, KMS, KC, and KFS) . These 
modules, in turn, are further decomposed into the 
necessary functions and procedures to accomplish the 
appropri ate tasks. 

2 . Te chniques for Software Dey eiggmen t 

In order to achieve our design goals, it is 
important to employ effective ^ software engineering 
techniques during all phases of the* software development 
life— cycle. These phases, as defined by Ledthrum CRef. 11: 
p. 271, are as follows: 



(1) Requirements Specif ication — This phase involves 

stating the purpose of the software: what is to be 

done, not how it is to be done. 

(2) Design - During this phase an algorithm is devised 
to carry out the specif i cati on produced in the 
previous phase. That is, how to implement the sys- 
tem which is specified during this phase. 

(3) Coding — During this phase the design is translated 
into a programming language. 

(4) Validation - During this phase it is ensured 
that the developed system functions as originally 
intended. That is, it is validated that the system 
actually performs what it is supposed to do. 

The first phase of the life— cycle has already 
been performed. The research done by Demur ji an and Hsiao 
CRef. 11 has described the motivation, goals, and 

structure of the MLDS. The research conducted by liacy 
CRef. 21 and Rollins CRef. 31 has extended this work to 

describe in detail the purpose of the SQL interface- 
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Hence, the requirements specification is derived from the 
above research. 

We have developed the design of the system using 
the above specification. A Systems Speci f i cati on Language 
(SSL) CRef. 123 is used extensively during this phase. The 
SSL has permitted us to approach the design from a very 
high-level, abstract perspective by : 

(1) enhancing communications Itmong program^ team 
members, 

(2) reducing dependence on any one individual , and 

(3) producing complete and accurate documentation 
of the design. 

Furthermore, the SSL has allowed us to make an easy 
transition from the design phase to the coding phase. 

We have used the C programming language CRef. 133 to 
translate the design into executable code. Initially, we 
were not conversant in the language. ^ However, our 
background in Pascal and the simple syntax of C have made it 
easy for us to learn. The biggest advantage of using C is 
the programming environment that it resides (i-e., the UNIX 
operating system). This environment has permitted us to 
partition the SQL interface and then manage these parts 
in an effective and efficient manner- Perhaps, the only 
disadvantage with using C is the poor error diagnostics, 
having made debugging difficult. There is an on-line 

debugger available for use with C in UNIX for debugging. 
We have avoided. this option and instead used 
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conditional compilation and diagnostic print statements 
to aid in the debugging process. To validate our 
system we have used a traditional testing technique, 
i.e., path testing CRef. 141. We have checked boundary 
cases such as the nested select and the single select. 
And we have tested those cases considered "normal “. It 
is noteworthy to mention that testing, as we have done it, 
does not prove the system correct, fiut can only indicate 
the absence of problems with the-' cases that have been 
tested. 

Char acteri stipes of the Interface Software 

In order for the SQL interface to be successful , 'we 
have realized that it must be well designed and well 
structured. Hence, we are cognizant of certain 
character i sti cs that the interface must possess. 
Specifically, it must be simple. In other words, it must be 
easy to read and comprehend. The C code we have ’written 
has this characteri st i c . For instance, we often write the 
code with extra lines to avoid shorthand notations 
available in C. These extra lines have made the 
difference between comprehensible code and cryptic 
notations. 

The interface software also must be under standabi e. 
This must be true to the extent that a maintenance 
programmer, for example, can easily grasp the 
f uncti onal i ty of the interface and the relation betv*jeen it 
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and the other pieces of the system. Our software 
possesses this characteristic- and does not have any hidden 
side— effects that could pose problems months or years from 
now- As a matter of fact, we- have intentionally 
minimized the interaction between procedures to alleviate 
this problem. 

The interface must also be maintainable. This is 
important in light of the fact that almost 70X pf all of 
th4- software life— cycle costs are incurred after the 
software becomes operational, i.e., in the maintenance 
phase- There are softi-^are engineering techniques we 
employed that have given the SQL interface this 
characteri sti c . For example, we require programmers to 
document changes to the interface code when the change is 
made. Hence, maintenance programmers have current 
documentation at all times. The problem of trying to 
figure out the functionality of a program with dated 
documentati on is alleviated. We also required the 
programmers to update their SSL specification as the code is 
being changed- Thus, the SSL specification consistently 
corresponds to the actual code. In addition, the data 
structures are designed to be general- Thus, it is an easy 
task to modify or rectify these structures to meet the 
demands of an evolving system. 

The research conducted by Demur ji an and Hsiao 
CRef. 11 provides a high-level specification of the MLDS- 
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The theses written by Macy CRef, 2J and Rollins CRef - 3D 
extend the above work and provide a more detailed 
sped -fi cation of an SQL language interface. This 
thesis outlines the actual implementation of an SQL 
interface- The appendices provide the specification SSL 
for this implementation. 

A final character i sti c * that an SQL interface should 
have is extensibility- A software product must be designed 
in\a manner that permits the easy modification and addition 
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horizontal screens of output. In addition, we have 
designed our data structures in a manner that will 
permit subsequent programmers to easily extend them to 
handle not only multiple users, but also other language 
interf aces- 

C- A CRITIQUE OF THE DESIGN 

Our implementation of the SQL interface possesses all of 
the elements of a successful software product- As noted 
previously, it is simple, understandable, maintainable, and 
extensible. Our constant employment of modern software 
techniques have ensured the success- 

However , there are two techniques that are especially 
worthy of critiques- The first of these is the use 
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of the SSL. Initially, we have felt that the 
i mpl enient ati on language may also serve as the language to 
specify program algorithms. However, in doing so, we have 
stifled our creativity. This is because we are 
concentrati ng not only on what the algorithm does, but 
also on what the constructs (data structures) of the 
algorithm are. The use of the SSL has permitted us to 
concentrate on the functionality of “X the algorithm without a 
heavy concentrati on on its parti cul ar -.constructs. This has 
allowed us to view the algorithm in a detached manner so 
that the most effi-cient implementation for the 
constructs can be used. Although we have initially felt 
that the development of the program with the SSL may be too 
time-consuming, our opinions are changed when we have 
realized the advantages of the SSL and the overall 
complexity of the SQL language interface. 

.The way in which the data structures are designed is 
the other noteworthy software engineering technique. 
Being relatively inexperienced programmers, we are 
inclined to use static structures. Hence, we have made 
extensive use of structures which are bound at compile time- 
We soon realize that in doing so, the computing resources 
(e.g., data space) of the system are being depleted quite 
rapidly. Therefore, it is necessary for us to design the 
data structures in a way that they can be managed in a 
dynamic fashion- Most of the data structures of the 
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SQL interface are linked lists. This design affords us 
the most convenient way to efficiently utilize the 
resources of the system. It is an easy task to use the C 
language's malloc (memory allocate) function to 
dynamically create the elements of a list as we have needed 
them. In addition, the free command is useful in 
releasing these same elements to be used again. 

D. . THE DATA STRUCTURE 

The SQL language interface has been developed as a 
single user system that at some point will be updated to a 
multi-user system. *Two different concepts of the data are 
used in the language interface 

1. Data shared by all users. 

2. Data specific to each user. 

The reader must realize that the data structures used 
in our interface and described below have been 
deliberately made generic- Hence, these same structures 
support not only our SQL interface, but the other language 
interfaces as well, i.e., DL/I, CODASYL-DML , and Daplex. 

1 • Data Shared by Al_^ Users 

The data structures that are shared by all users 
are the database schemas defined by the users thus far. 
In our case, these are relational schemas, consisting 
of relations and attributes. These are not only shared 
by all users, but also shared by the four modules of the 
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MLDS, i.e. , LIL, KMS, KC, and KFS. Figure 3 depicts the 
first data structure used to maintain data- It is 
important to note that this structure is represented as 
union. Hence, it is generic in the sense that a user can 
utilize this structure to support SQL, DL/I, CODASYL-DML, 
or Daplex needs. However, we will concentrate only on 
the relational model. In this regard, the first field of 
this structure points to a record that .'contains 
information about a relational • database. Figure 4 
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union dbid_node 
f 

struct rel_dbid_node *rel ; 

struct hi e_dbi d_node *hie; 

struct net_dbi d_node *net; 

struct ent_dbi d_node *ent; 

> 



Figure 3- The dbid_node Data Structure. 



struct rel 

char 
i nt 

struct 

struct 

struct 



dbi d_node 

nameCDBNLength + ID; 
num_rel ; 

rel_node *f irst_rel ; 

rel_node *curr_rel ; 

rel _dbi d_node *nex t_db; 



Figure 4. The rel _dbi d_node Data Structure 



representing the number o-f relations in the database. The 
third and -fourth -fields are pointers to other records 
containing in-formation about each relation in the database. 
Speci-f ical ly , the third -field points to the -first relation 
in the database while the -fourth -field points to the 
current relation being accessed. The final field is just a 
pointer to the next relational database. 

The record rel_node contains^ inf ormation about each 
relation in the database. <See Figure 5.) This structure 
is organized in much the same fashion that the rel _dbi d_node 
is organized. The first field of the record holds the name 
of the relation. The next field contains the number of 
attributes in this relation. The third and fourth fields 
point to other records which contain data on the first 
and current attribute of this relation. And finally, 
the last field is a pointer to the next relation in this 
database. 



struct rel_node 
i 

char 
i nt 

struct rattr_node 

struct rattr_node 

struct rel node 



nameCRNLength + 13; 
num_attr ; 

♦f irst_attr; 
*curr_attr ; 

♦nex t_rel ; 



Figure 5. 



The rel node Data Structure. 



Figure 6 shows the structure o-f the final record 



type used to support the definition of the relational 
database schema. The first field is also an array, 
holding, in this case, the name of the attribute. The 
second field serves as a flag to indicate the attribute 
type. For instance, an attribute can either be an integer, 
a floating point number, or a string. The characters 
"i", "f", and '"s'* are used, respectively. The third 
field indicates the maximum length that a value of this 
attribute type may possibly have. For example, if this 
field is set to ten and the type of this attribute is a 
string, then the maximum number of characters that a 
value of this attribute type may have is ten. The fourth 
field is also a flag used to indicate whether or not 
this particular attribute is a key. The last attribute 
just points to the next attribute in this relation. The 
reader may refer to Appendices B through E to examine how 
these data structures are used in the SSL. 



struct rattr node 



char 

char 

int 

int 

struct 



rattr node 



nameC ANLength + 11; 
type; 

1 ength ; 
key_f 1 ag; 

*nex t ; 



Figure 6- The rattr^node Data Structure. 



2. Data Speci -f ic to E ac h Us er 

This category o-f data represents information 

needed to support each user's particular interface 
needs. The data structures used to accomplish this can 

be thought of as forming a hierarchy- At the root of this 
hierarchy is the record type user_info that maintains 
information on all of the current users of a particular 
language interface. (See Figure 7.)^ The user_info record 
hoI,ds the ID of the user ^ a union that describes a 

particular interface, and a pointer to the next user. The 
union field is of particular interest to us. As noted 
earlier, a union serves as a generic data structure. In 

this case, the union can hold the data for a user accessing 
either an SQL language interface, a DL/I LIL, a CODASYL- 
DML LIL, or a Daplex LIL- The li_info union is shown in 
Figure B. 

We are only interested in the data structures 

containing information for each user that pertains to the 
SQL language interface. This structure is referred to as 

struct user_info 

,r 

L 

char uidCUIDLength + 11; 

union li_info li_type; 

struct user_info ■»next_user; 

J" 

Figure 7. The user_info Data Structure. 
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union li_info 
C 



struct 


sql_inf o 


sql ; 


struct 


dl i_inf o 


dl i ; 


struct 


dml _inf o 


dml ; 


struct 


dap_inf o 


dap; 



> 

Figure 8. The li_in*fo Data Structure. 

sql_info and is depicted in Figure 9. The first field of 
this structure, curr _db_inf o , isj itself a record and 

coT>tains currency information on the database being accessed 
by a user. The second field, file, is also a record. The 
file record contains the file descriptor and file identifier 
of a file of SQL tr ansact i ons , i.e., either queries or 

creates. The next field, sql_tran, is also a record, and 
holds information that describes the SQL transactions 
to be processed. This includes the number of requests to 
be processed, the first request to be processed, and the 
struct sql_info 



struct 


curr_db_i nf o 


curr_db ; 


struct 


f i le_inf o 


file; 


struct 


tran_i nf o 


sql _tran ; 


int 




operation ; 


struct 


ddl _i nf o 


*ddl _f i 1 es; 


struct 


tran_i nf o 


*abdl _tran ; 


uni on 


kms_i nf o 


kms^data; 


union 


kf s_inf o 


kf s_data; 


union 


kc_inf o 


kc_data; 


int 




. error ; 



The sql_info Data Structure. 



Figure 9. 



current request being processed. The fourth -field of the 
sql_info record, operation, is a flag that indicates the 
operation to be performed. This can be either the loading 
of a new database or the execution of a request 
against an existing database- When this field represents 
the execution of a request, it is encoded with the ABDL 
request type to be executed. The next field, ddl_files, 
is a pointer to a structure descriijing the descriptor file 
and' template file- These files contain information about 
the ABDL schema corresponding to the current relational 
database being processed, i-e. the ABDL schema 
information for a newly defined relational database. The 
sixth field, abdl_tran, is a pointer to a record that 
describes the ABDL equivalents to the transactions written 
in SQL i-e., the translated SDL requests. 
Specifically, this is the first ABDL request, the current 
ABDL request, and the number of ABDL requests to be 
processed. This data is provided by the KMS and used by 
the KC- The next three fields, kms_data, kc_data, and 
kfs_data, are unions that contain information that is 
required by the KMS, KC, and KFS. These will be described 
in more detail in the next four chapters- The last 
field, error, is an integer value representing a specific 
error type- 
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E. THE ORGANIZATION OF THE NEXT FOUR CHAPTERS 



The following four chapters are meant to provide the 
user with a more detailed analysis of the modules 
constituting the MLDS. Each chapter will begin with an 
overview of what each particular module does and how it 
relates to the other modules- The actual processes 
performed by each module are then discussed. This includes a 
description of the actual' data s-^ructures used: by the 
modules. Each chapter concludes -with a discussion of 
modul e shortcomi ngs- 
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III. 



THE LANGUAGE INTERFACE LAYER (LID 



The LIL is the first module in the SQL mapping process, 
and is used to control the order in which the other 
modules are called. The LIL allows the user to input 
transactions from either a file or the terminal. A 
transaction can take the form of either creates For a new 
database or queries against an existing database. JThe 
mapping process takes place when the LIL sends a sing!^e 
transaction ±o _ the , KMS. After the transaction has been 
received by the KMS, the KC is called to process the 
transaction. Control always returns to the LIL, where the 
user can close the session by exiting to the operating 
system. 

The LIL is menu-driven. When the transactions are read 
from either a file or the terminal they are stored in a data 
structure called rel _req_inf o. " If the transactions are 
creates they are sent to the KMS in sequential order. If 
the transactions are queries the user will be prompted by 
another menu to selectively pick an individual query to be 
processed. The menus provide an easy and efficient way to 
allow the user to see and select the methods in which to 
perform the mapping functions. Each menu is tied to its 
predecessor so that by exiting each menu the user is being 
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moved up the menu “tree'*. This allows the user to perform 
multiple tasks in one session. 

A. THE LIL PROCESS 

In this section we discuss the processes and actions 
performed by the LIL. These processes are presented in 
the order in which they are encountered during a 

typical session. The data structures used heavily by 

•% 

the LIL are discussed first. 

1 . I mp o rtant Data St ructures 

The LIL uses two data structures to store the 
user's transactions .and to control which transaction is to 
be sent to the KMS. It is important to note here that 
these data structures are shared by both the LIL and the 
KMS. 

The -first structure is named tran_info and is shown 
in Figure 10. The first field of this record, first_req, 
contains the address of the first transaction of the 
transaction list that was read from a file or the 
terminal. The second field, curr_req, contains the 






struct tran_info 
r 



r< 



struct rel_req_info -t^-f i rst_req ; 
struct rel_req_info *curr_req; 
int no_req; 



Figure 10. The tran_info Data Structure. 
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address of the transaction currently being processed. 
The LIL sets this pointer to the transaction that the KMS 
will next process, and then calls KMS. The third field, 
no_req, contains the number of transactions currently in 
the transaction list. This number is used for loop 

control when printing the transaction list to the screen or 
when searching the list for a transaction to be executed. 

The second data structure ased by LIL is named 

% 

rel^req^inf a. Each copy o-f thi s .structure represents a 
user transaction and thus, is an element of the 

transaction list. The rel_req_info is given in Figure 11- 
The first field of this record, req, is a character string 
that contains the actual SQL transaction- The second 
field, in_req, is a pointer to a list of character arrays 
that each contain a single line of one transaction- 
After all lines of a transaction have been read, the 
line list is concatenated to form the actual 
transaction, req- The third field of this structure, 

req_len, contains the number of characters the transaction 

struct r el _req_i nf o 
C 

char *req; 

struct temp_str_inf o *in_req; 

int req_len; 

struct rel_req_info *next_req; 



Figure 11- The rel_req_info Data Structure. 
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occupi62S. It is used to allocate the correct and 

minimal amount of memory space for the transaction. The 

last field, next_req, is a pointer to the next transaction 
structure rel_req_inf o, in the transaction list. 

2 . sdur es and Functions 

The LIL makes use of a number of procedures and 
functions in order to create the transaction list, pass 
elements of the list to the KMS, aAd maintain the- database 
schemas- Each of these procedures ;and functions will not 
be described in detail, but a general description of the 
LIL process will be discussed- 
a. Initialization 

The liLDS is designed to be able to accommodate 
multiple users, but is implemented to support only a single 
user. To facilitate the transition from a single— user 
system to a multiple user system, each user possesses his 
own copy of a user data structure when entering the 
system- This user data structure stores all of the 

relevant data that the user may need during their session. 
All four modules of the mapping process make use of this 
structure. The modules use many temporary storage 
variables in performing their tasks or for passing data 
between modules- The transact i ons , in user data 

language and mapped kernel data language form, are also 
stored in each user data structure. It is easy to see 
that the user structure provides consolidated, centralized 
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control for each user o*f the system. When a user logs onto 
the system, a user data structure is allocated and 

initialized- The user ID becomes the distinguishing 

feature to locate and identify different users- The 
user data structures for all users are stored on a linked 
list so that when a new user enters the system, their 
initialized user data structure is appended to the end of' 
the list. In our current environment there is only a single 
element on the user list. In a future environment, when 
there are multiple users, we simply adopt the append 
operation mentioned above. 

b. Creating the Transaction List 

There are two operations the user can 
perform on the database schemas- A user can create a 

new database or process queries against an existing 

database- The first menu that is displayed prompts the 

user for which function to perform- Each function 
represents a separate procedure to handle the specific 
circumstances- This menu looks like the following: 

Enter type of operation desired 
(1) - load a new database 

(p) - process old database 
(x) — return to the operating system 

ACTION > 

For either choice (i-e-, 1 or p) , another menu 
is displayed to the user asking for the mode of input- 
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This input may come from a data file or interactively from 
the terminal. The generic menu looks like the following: 

Enter mode of input desired 

<f) — read in a group of transactions from a file 
<t) — read in transactions from the terminal 
(x) - return to the previous menu 

ACTION > 

Again, each mode of input picked corresponds to a 
different procedure to be performed. The transaction list 
is created by reading from the’ file or terminal 
looking for an end— of -transact i on marker or an end-of- 

file marker. . These. flags tell the system when one 
transaction has ended and when the next transaction 
begins. When the list is being created, the pointers to 
access the list must be initialized. These pointers, 

first_req and curr_req, have been described earlier in the 
data structure' section. Both pointers are set to the 

first transaction read, in other words, the head of the 
transaction list. 

c- Accessing the Transaction List 

Since the transaction list stores both creates 
and queries, two different access methods must be 

employed to send the two types of transactions to the 
KMS- We discuss the two methods separately- In both 

cases the KMS accesses a single transaction from the 
transaction list- It does this by reading the transaction 
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pointed to by the request pointer, curr_req, ot the data 
structure, tran^info. (See Figure 10 again.) Therefore, it 
is the job of the LIL to set this pointer to the 
correct transaction before calling the KMS. 

(1) Serjding Creates to the KMS. When the user 
has specified the filename of creates (if the input is from 
a file) or typed in a set of creates (if the input is from 
the terminal), any further use^ i nterventi on_ is not 
required. To produce a new database, it does not make sense 
to process only a single create out of a set of creates, 
since they all must be processed in a specific order. 
Therefore, the transaction list of creates is sent to the 
KMS in its entirety. A program loop traverses the 
transaction list, calling the KMS for each create in the 
list. 

(2) Sending Queries to the KMS. In this 
case, after the user has specified his mode of input, 
he conducts an interactive session with the system- First, 
all queries are listed on the screen. As the queries are 
listed from the transaction list, a number is assigned to 
each query in ascending order, starting with the number one. 
The number is printed on the screen to the left of the 
first line of each query. Next, an access menu is 
displayed which looks like the following: 
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Pick the number or letter o-f the action desired 

(num) — execute one o-f the preceding queries 
(d) — redisplay the list o*f queries 

<x) — return to the previous menu 

ACTION > 

Since queries are independent items, the order in which 
they are processed does not matter. The user has the 
choice o-f executing any number o-f queries- A loop causes 
the query listing and menu to 6e redisplayed 'a-fter any 
qu^y has been executed so that -further choices may made, 
d- Calling the KC 

As mentioned be-fore, the LIL acts as the 
control module -for the entire system. When the KMS has 

completed its mapping process, the trans-formed 

transactions must be sent to the KC to interface to the 
kernel database system. For creates the KC is called 

after all creates on the transaction list have been sent 

to the KMS. The mapped creates reside in another list 

that the KC is going to access. Since queries are 

independent items, the user should wait for the results from 
one query before issuing another query. Therefore, after 
each query has been sent to the KMS, the KC is immediately 
called. The single mapped query resides on the same second 
list for the creates which the KC can access easily, 
e. Wrapping— up 

Before exiting the system, the user data 

structure described in Chapter II must be deallocated- The 
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memory occupied by the user data structure is -freed up and 
returned to the operating system. Since all o-f the user 
structures reside in a list, the exiting user's node must 
be removed -from the list. 

B. SHORTCOMINGS 

As used in this chapter, a transaction consists o-f a 
single request on a database. A transaction would normally 
be allowed to contain multiple requests, such as an 
insert, a query, and then a modify on some portion of a 
database- This feature is not incorporated into the 
present system ,1. but. it could be easily integrated at some 
later date- 
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IV 



THE KERNEL MAPPING SYSTEM (KMS) 



The KMS is the second module in the SQL mapping 
interface and is called from the language interface layer 
(LID when the LIL has received SQL input requests from the 
user. The function of the KMS is to: <1) parse the request 
to validate the user's SQL syntax , Bnd (2) translate, or 
map, the request to an equivalent ;ABDL request. Once an 
appropriate ABDL request, or set of requests, has been 
formed, it ,i s made ,avai 1 abl e to the. kernel controller (KC) 
which then processes the request for execution by MBDS. The 
KC is to be discussed in Chapter V. 

A. AN OVERVIEW OF THE MAPPING PROCESS 

From the description of the KMS functions above we 
immediately see the requirement for a parser as a part of 
the KMS. This parser validates the SQL syntax of the input 
request- It is the driving force behind the entire mapping 
system. 

^ tSyS Parser / Jransl atgr 

The KMS parser has been constructed by utilizing 
Yet— Another-Ccmpi 1 er Compiler (YACC) CRef. 15j. YACC is a 
program generator designed for syntactic processing of token 
input streams- Given a speci f i cati on of the input language 
structure (a set of grammar rules), the user's code to be 
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invoked when such structures are recognized, and a low— level 
input routine, YACC generates a program that syntactically 
recognizes the input language and allows invocation o-f the 
user's code throughout this recognition process. The class 
o-f speci-f ications accepted is a very general one: LALR ( 1 ) 
grammars. It is important to note that the user's code we 
speak o-f . here is our mapping code that is going to perform 
the SQL-to-ABDL translation. As Jthe low— level input 
routine, we have utilized a Lexical Analyzer Generator (LEX) 
CRef. 163. LEX is a program generator designed for lexical 
processing of input character streams. Given a regular- 
expression description of the input strings, LEX generates a 
program that partitions the input stream into tokens and 
communicates these tokens to the parser. 

The parser produced by YACC consists of a finite- 
state automaton with a stack and performs a top-down parse, 
with 1 ef t-to-r i ght scan and one token look-ahead. Control 
of the parser begins initially with the highest-level 
grammar rule. Control descends through the grammar 
hierarchy, calling lower and lower-level grammar rules which 
search for appropriate tokens in the input. As the 
appropriate tokens are recognized, some portions of the 
mapping code may be invoked directly. In other cases, these 
tokens are propagated back up the grammar hierarchy until a 
higher — level rule has been satisfied, at which time further 
translation is accomplished. When all of the necessary 
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lower level grammar rules have been satisfied and control 
has ascended to the hi ghest-1 evel rule, the parsing and 
translation processes, and, therefore, the mapping process, 
is complete- In Section B, we give an illustrative example 
of these processes. 

2- The KMS Data Structures 

The KMS utilizes, for the most part, just four 
structures -defined in the interface. It, naturally, 
requires access to the SQL input request and ABDL output 
request structures discussed in Chapter II, the rel_req_info 
and ab_req_info structures, respectively- However, the four 
data structures to be discussed here are only those unique 
to the KMS- 

The first of these, shown in Figure 12, is a record 
that contains information accumulated by the KMS during the 
grammar-dri ven parse that is not of immediate use- This 
record allows the information to be saved until a point in 
the parsing process where it can be utilized in the 
appropriate portion of the translation process. The first 
field in this record, first_tgt, is a pointer to the head of 
a list of attribute names-' These are the attribute names 
specified by the user request to retrieve information from, 
or insert information into, the database- This list is only 
utilized during SELECT or INSERT operations- The second 
field, templates, is also a record and holds the relation 
name(s) referenced in the user query- During join 
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struct rel_kms_in-f o 
i 

struct target_l i st_i n-f o 
struct tempi ates_i rvfo 
struct insert_list_in-fo 
char 
char 

struct rel _kms_i n-f o 



■«"f irst_tgt ; 
tempi ates; 
-»-f irst_val ; 
-»temp-str ; 
■»join_str ; 
♦nex t_nest ; 



Figure 12. The rel_kms_in-fo Data Structure. 

operations, two relation names may be kept in this record. 
The third -field, -first_val , is a pointer to the head o-f a 
list o-f values. These are the values that an INSERT request 
desires inserted into the database. The fourth field, 
temp_str, is a pointer to a variable-length character 
string. The character-stri ng length is a function of the 
input request length, and is allocated, when required, to 
accumulate intermediate translation results while parsing 
the WHERE boolean-clause of a user request. The fifth 
field, join_str, is also a pointer to a variable length 
character string. The character — string length is again a 
function of the input request length, and it is allocated to 
accumulate the translation for the second ABDL RETRIEVE 
request that is generated in response to a join operation. 
The sixth field, next_nest, is a pointer to another record 
of the same type. The next_nest field is used only during 
the translation of a nested SELECT statement, in which case 
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we require a list o-f rel_kms_info structures, one 
correspondi ng to each level of the nested SELECT query - 

The remaining three data structures, shown in Figure 
13, are records that are painted to by the rel_kms_inf o 
record, as just described. Respectively, they represent a 
list of attribute names (the target list), a record of 



rel ati on 


names 


(the templates). 


and a list 


of attribute 


val ues 


(the 


insert list). 


ANLepgth and 


RNLength 
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attribute 


and 
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names 
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It should be 


noted that 
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the insert_list_ 


info record is 


a pointer 


to a 



variable length character *stri ng . Although attri but e— names 
have a constant maximum length constraint, the length of 



struct target_l i st_inf o 

char nameC ANLenqth -h 13; 

char tgt_rel CRNLength -h 13; 

struct t ar get_l i st_i nf o *nex t_attr ; 



struct tempi at es_info 
C 

char namel CRNLength + 13; 

char name2CRNLength + 13; 



struct i nsert_l i st_inf o 

char lvalue; 

struct insert list__info *next_val; 



Figure 13- Additional KMS Data Structures. 
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attribute values in 


the 


database 


i s 


limited 


only 


by the 


constraint placed 


on 


them by 


the 


user 


i n the 


original 


database def i ni t i on 


, and 


as such 


they 


may 


be of 


varying 



1 engths. 

At the end o-f the mapping process, be-Fore control is 
surrendered to the LIL, all data structures that are unique 
to KMS which have been allocated during the mapping process 
are returned .to the free list. ' 

B. ' FACILITIES PROVIDED BY THE IMPLEMENTATION 

In this section, we discuss those SQL facilities that 
are provided *fay qur implementation of the’ relational 
interface. We do not discuss the SQL to ABDL translation in 
detail. Rather, we provide an overview of the salient 
features of the KMS, accompanied by one illustrative e>iampie 
of the mapping process- User-issued requests may take two 
forms, SQL database definitions, or SQL database 
manipulations- Appendix C contains the design of our 
implementation, written in a system speci f i cat i on language. 

1 - D^t^base Definitions 

When the user informs the LIL that the user wishes 
to create a new database, the job of the KMS is to build a 
relational database schema that corresponds to the database 
definitions input by the user. The LIL initially allocates 
a new database identification node (rel dbid node shov^n in 



Figure 4) with the name of the new database, as input by the 



user • The LIL then sends the KMS one database definition at 
a time, which takes the form of an SQL CREATE TABLE request 
as follows: 

CREATE TABLE table_name : 

field_name_l ( type(length) C, NONULLl ), 
field_name_2 ( type(length) C , NONULLl ), 

field_name_n ( typfe( length) C, NONULLl ) 

For each CREATE TABLE request, an additional relation node 
(rel^node shown in Figure 5) is added to the database schema 
under construction. It should be apparent from the 
preceding CREATE TABLE example that for each relation node, 
we must also add a list of attribute nodes (rattr_node shown 
in Figure 6) to the schema. The database identification 
node holds the number of relations in the schema and the 
database name, each relation node holds the number of 
attributes in that relation and the relation name, and each 
attribute node holds the attribute name, type, length, and 
primary key information. 

When the LIL has forwarded all database definitions 
entered by the user, the result is a completed database 
schema, -as shown in Figure 14. The relational database 
schema, when completed, serves two purposes. First, when 
creating a new database, it facilitates the construction of 
the MBDS template and descriptor files- Secondly, when 



! DBID ! 

H + 



! REL 1 ! — > i ATTR 1 I — > ! ATTR 2 I — > 



— >! ATTR i 



! REL 2 I — > I ATTR 1 ! — > I ATTR 2 1 — > ... — >! ATTR j I 



REL_n I—: 

h 



I ATTR 1 1 — > I ATTR 2 1 — > 



Figure 14. The Relational Database Schema. 



processing requests against an existing database, it allows 
a validity check o-f the relation and attribute names. It 
also serves as a source o-f in-formation for the type 
checking. 

2. Database Mani gul_atigns 

When the user wishes the LIL to process requests 
against an existing database, the job of the KMS is to map 
the user's SOL request to an equivalent ABDL request. 
Throughout this subsection, v^ie only provide examples of the 
translated constructs of our implementation where they 
differ in some respect from those given in the work of Macy 
CRef. 21 and Rollins CRef. 31. 
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a. The SQL SELECT to the ABDL RETRIEVE 

A simple SQL SELECT construct is mapped to a 
single ABDL RETRIEVE construct. A simple SELECT is 
char acter i zed as a SELECT— FROM— WHERE block, in which access 
is limited to the in-formation contained in a single relation 
of the database. The SELECT— cl ause may contain attribute 
names alone, or the aggregate functions (COUNT, SUM, AVG, 
MAX, and MIN> may be applied to any C)f the attributes where 
it -makes sense to do so. The SELECT— cl ause may also contain 
an asterisk (*) , which signifies that all attributes in the 
relation should be retrieved, in lieu of an exhaustive 
listing. As a final option, the attribute ‘names may be 
prefixed with the relation name (rel _name- attr_name) , even 
though only a single relation is being accessed. The FROM— 
clause contains this single relation name. The WHERE-clause 
may contain any number of predicates connected together by 
th^ boolean operators (AND and OR). Each predicate may 
utilize the six standard relational operators (=, /=, >, >=, 
<, and <=) to separate the attribute name and value, or the 
set membership operators (IN, NOT IN, /=ANY, <=ANY, <ANY, 
>ANY, >=ANY, <=ALL, <ALL, >ALL, >=ALL) may be used to 
separate the attribute name from an enumerated set of 
values. Finally, the SELECT— FROM— WHERE block may be 
optionally followed by either a GROUP BY-clause, or an ORDER 
BY-clause, whereby retrieved attributes may be either 



grouped or sorted. 



A nested SQL SELECT construct is mapped to a 
series o-f ABDL RETRIEVE constructs. A nested SELECT is 
characterized as a SELECT— FROM— WHERE block, in which the 
WHERE— clause utilizes one o-f the set membership operators. 
In this instance, however, the operator is -followed by 
another complete SELECT-FROM— WHERE block instead o-f an 
enumerated set o-f values. Such constructs can be nested to 
any depth. This allows multiple relations to be accessed, 
and' their attri bute— val ues compared, while the values 
returned to the user are taken from only a single relation. 
This is analogous to an implicit join operation.- An example 
of such a query is as follows: Note that the parentheses are 
optional and need not be included. 

SELECT name, age 
FROM student 
WHERE name IN 

( SELECT name 

FROM faculty ) 

This query would find the name and age of all students who 
are also a member of the faculty. It's ABDL counterparts 
would be as follows: 

C RETRIEVE (TEMPLATE = FACULTY) (NAME) 1 

C RETRIEVE ( (TEMPLATE = STUDENT) and 

(NAME = ***********)) (NAME, AGE) 1 
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Notice that the first ABDL request corresponds to the last 
(or innermost) SQL request. This is because the innermost 
SQL request is the only one that represents a completely 
specified simple SELECT. The results of the first RETRIEVE 
are names which are used by the KC to fill in the place 
holders marked with asterisks in the second RETRIEVE (the 
number of asterisks equals the maximum length of the NAME 
attribute-value). From a single ^nested SELECT;, the KMS 
generates a series of ABDL RETRIEVES • before relinquishing 
control to the KC, for subsequent execution of the ABDL 
requests. 

A join SQL SELECT construct is mapped to a 
single ABDL RETRIEVE-COMMON construct- A join SELECT is 
characterized as a SELECT-FROM-WHERE block, in which the 
FROM-clause contains two relation names. We have already 
seen how the nested SELECT query specifies an implicit join- 
Here we are concerned with explicit joins, where multiple 
tables are accessed, and their attribute values compared, 
with the values returned to the user being taken from two 
different relations. In this instance, the SELECT— cl ause 
normally contains attribute-names that are prefixed with the 
appropriate, relation name (rel_name- attr_name) . This 
eliminates any ambiguity that might otherwise exist- The 
prefixed attri bute— names are a required convention in the 
WHERE-cl ause . An example of such a query is as follows: 
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SELECT 

FROM 

WHERE 



student, name, -faculty, name 

student, -faculty 

student . cl ass = f acul ty . cl ass 



Assumi ng 


each class was 


only taught by 


one member 


of 


the 


f acul ty , 


this query 


would return 


a class roster 


for 


all 


members 


o-f the -faculty- 


It's ABDL counterpart would 


be 


as 



f ol 1 ows: 



C RETRIEVE (TEMPLATE = STUDENT) (NAME) 

COMMON (CLASS = CLASS) 

RETRIEVE (TEMPLATE = FACULTY) (NAME) 1 

Notice the placement of the square brackets around the ABDL 
request. This represents a single ABDL request, and is 
forwarded to MBDS for execution as a single transaction. 
The use of prefixed attribute names in the SELECT-cl ause is 
not a necessity, providing that the attribute-names used are 
valid in both relations. Thus, the last SQL example may be 
entered as shown below to obtain the same results. 

SELECT name 

FROM student, faculty 

WHERE student . cl ass = f acul ty. cl ass 

b. The SQL INSERT to the ABDL INSERT 

The SQL INSERT construct is mapped to a single 
ABDL INSERT construct- If values are to be inserted for 
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each attribute in the relation, there is no requirement to 
list the attribute names. Only the- attribute values need be 
listed; however , they must appear in the correct order (as 
listed in the schema which has been determined during the 
OJ^igiri^l database definition of the relation). If values 
are not inserted for each attribute in the relation, 
correspondi ng attribute names of those attribute values to 
be inserted must also be included in,Jthe request. 

c. The SQL UPDATE to the ABDL UPDATE 

The SQL UPDATE construct is mapped to a single 
ABDL UPDATE construct. ABDL does not provide a single- 
request construct which updates more than one attribute in a 
record. Thus, we only allow one predicate in the SET-clause 
of the SQL UPDATE query. However, the attribute value in 
this predicate may be a constant, or an arithmetic 
e;<pression based on the original value of the attribute. 

d. From the SQL DELETE to the ABDL DELETE: An 

Ex amp 1 e 

The SQL DELETE construct is mapped to a single 
ABDL DELETE construct. The SQL DELETE may have an optional 
WHERE— cl ause , so that all records for the particular 
relation may be deleted when the WHERE-clause is empty, or 
only those records satisfying a specific condition may be 
deleted when the WHERE-clause is included. In this 
subsection we will present an illustrative example of the 
mapping process for a simple SQL DELETE request. We begin 
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by showing the grammar -for the delete-portion o-F the KMS. 
We then step through the grammar and show appropriate 
portions of our design in System Specification Language 
(SSL) . The entire design is shown in Appendix C. The 
relevant grammar is as follows: 

deletion : DELETE table_name E; 

table_name : IDENTIFIER;^ 

E : empty 

I WHERE boolean; 

empty : ; 

bobl ean : * . . . ; 

The source SOL request we will utilize for our example will 
be the fallowing: 



DELETE student 

It's ABDL translation will be as follows: 

C DELETE ( TEMPLATE = STUDENT) 3 

To begin our discussion, let us first 
synchronize the readeri At the beginning of a mapping 
process, the parse descends the grammar hierarchy searching 
for appropriate tokens in the source that may satisfy one of 
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the grammar rules. Thus, the parser descends through the 
rules tor SELECTS, INSERTS, etc. After finding no matching 
tokens for those rules, the parser eventually descends on 
the DELETE rules. 

First, when the deletion rule is called, the 
DELETE-token will be recognized. In an attempt to satisfy 
the deletion rule, the table_name rule Is then called. The 
table_name rule recognizes the IDENTIFIER- token-', as the 
ST13DENT— token (student converted to upper— case upon input) . 
At this time, the tabl e_name-rul e is completely satisfied, 
and the following SSL is invoked: 

table^name : IDENTIFIER 

C 

if < ! creating) 

if (! val i d_tabl e ( ' tabl e_name ' ) ) 

print ("Error - rel_name not valid") 
perform yyerrorO 
r eturn 
end_i f 
end_i f 
>; 

If we are not creating a nev-^ database (as in this case) , a 
call is made to the val i d_tabl e ( ) function, which checks the 
validity of the IDENTIFIER table_name in the relational 
database schema. If STUDENT is not a valid relation name, 
then an error message is printed, and an error routine is 
called. Then we simply return from the mapping process. If 
STUDENT is a valid relation name, there is no code here for 
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control returns to the rule that 



tr ansi at i on ; however , 
called the table_name rule (i.e,, the. deletion rule). 

Next, even though the deletion rule is not 
completely satisfied, we need to perform some translation. 

The following SSL is invoked, before the call is made to the 
E— rul e: 

deletion*: DELETE table_name 

C 

copy DELETE ( “ to abdl^string 

copy 'table^name" to templates 

> 

E; 

The abdl_string begins to be built, as we initially copy 

DELETE ( “ 

into the abdl_string- The value of the table_name (STUDENT) 
is then copied to the templates data structure, because, at 
this point, we are not certain that it is of immediate use- 
The reader should note the trailing blank that we placed in 

the abdl_string- Without going into great detail, which is 

beyond the scope of this example, it suffices to say that 
this blank is for an additional left parenthesis that we may 
later determine to be required at the beginning of the ABDL 
request, i.e., when OR is used to connect WHERE-clause 
predi cates- 
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The next step in the parse is for the deletion 
rule to call the E— rule. The E— rule recognizes the empty 
rule, because the source is now void oT additional tokens. 
The E— rul e is now completely satisfied and the following SSL 
is invoked: 



E : empty 

C 

del Stegall = J-RUE 

*>. 

s 

1 WHERE boolean; 



This sets the delete_all boolean variable equal to true. 
Control now reverts to the deletion rule, which is of course 
completely satisfied. Thus, the following SSL is invoked: 



deletion : DELETE table^name 

E 

if (delete_all) 

concat "TEMPLATE = ' tabl e^name ' " 

to abdl_string 

end_i f 

concat '* ) " to abdl_string 



Since we know that the delete_ail variable has previously 
been set to true, we now concatenate 

"TEMPLATE = STUDENT" 



to the abdl_string- Finally, we concatenate the trailing 
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right parenthesis to the abdl_string. The trailing right 
bracket (3> is concatenated to the abdl_string after 
recognition of a higher — level grammar rule (one that called 
the deletion-rule), and the mapping process is now complete. 

Let us continue with an extension of this 
example. Had the original SQL source request included a 
WHERE bool ean— cl ause , such as the following, what would have 
happened? 

DELETE student 
WHERE name = 'Jones' 

Its ABDL equivalent is as follows: 

Z DELETE ( (TEMPLATE = STUDENT) and (NAME = Jones)) 3 

In this instance, when the E rule is called, the WHERE-token 
would have been recognized, and thus the boolean rule would 
have been called. The boolean rule would have called other 
rules and continued to read the /remainder of the input 
(source) tokens. Before the. boolean rule was called, the 
abdl_string contained the following: 

DELETE ( ” 

When control returns to the E-rule, from the boolean rule. 
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the abdl_string will contain the following: 



’'C DELETE ( (TEMPLATE = STUDENT) and (NAME = Jones)” 

Then control would revert from the E— rule to the deletion 
rule. But this time, since the delete_all variable is not 
set to true in the E-rule, the deletion rule merely 
completes this portion of the translation by concatenating 
anqxther right parenthesis to the abdl_string shown above. 
Again, the trailing right bracket is added at a higher 
level, and the mapping process is complete. 

C. FACILITIES NOT PROVIDED BY THE IMPLEMENTATION 

Our original intent has been to demonstrate that the 
relational interface could indeed be developed and 
implemented. As a demonstration, there are some facilities 
that are not included in our implementation. Some of these 
facilities have more to do with providing a user — friendly 
environment, than with supporting a germane relational 
interface- For others, the programming time and effort 
required to incorporate them would be too costly for the 
benefits derived. However, this is not to imply that such 
facilities would not be useful. This section is devoted to 
describing the most prominent features of SQL that are not 
supported by the language interface. 
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1 . lQtec£^£iQa Users 

In our relational interface, there is no concept of 
a user view, A view may be thought ^of as a virtual relation 
that has no existence in its own right, but is derived from 
one or more existing relations. Under our implementation, 
the logical database and the physical database are one in 
the same. Thus, our interface is limited to data ,def i ni t i on 
language (DDL) and data manipulation languag^e (DML) 
st^ttements, and provides no data— control facilities such as 
the GRANT and REVOKE options. Also, all CREATE TABLE 
requests are considered PERMANENT and SHARED. As mentioned 
in Chapter II, our interface data structures are constructed 
to facilitate future use by multiple users. This would 
allow the view concept to be supported by i ncorpor at i ng the 
relational database schemas into the user_i nf ormati on 
structure (user_inf o shown in Figure 7) . These schemas 
would be virtual and user — specific with respect to the 
entire list of database schemas that are still global . 

2. U&dati_ng Ml=LLtL&l.s 

ABDL does not provide a single-request construct 
which updates more than one attribute in a record- The work 
of Rollins CRef. 3: pp. 25-271 has showed that the SDL 
UPDATE may be translated into multiple ABDL requests- As a 
result, it may be necessary to generate either several 
independent ABDL UPDATES, a transaction of ABDL UPDATES 
(specifying the order in which a series of requests must be 
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processed) , or an ABDL RETRIEVE, DELETE, and INSERT 
sequence, to accomplish the requested update of multiple 
attributes. We have felt the programming effort involved to 
provide such a facility, although not complex, is time— 
consumi ng . 

Retrieving Qualified Groups 

ABDL provides an option whereby retrieved attributes 
may be sorted (the by— attri bute_namfc option). SOL' provides 
a further option whereby those records not satisfying a 
specified condition can then be eliminated (the HAVING- 
condition option). ABDL does not provide a facility for 
checking this specified condition. It could have been 
implemented in the KC; however, we have felt the programming 
effort is too great for the benefits derived. 

This option supports the inclusion of arithmetic 
expressions involving attribute names in the SELECT— cl ause 
of SQL requests. An example of this option is as follovis: 

SELECT name, weight * 454 
FROM student 

This query would retrieve the name and weight of all 
students. However, the value of the attribute v^eight would 
be returned to the user in grams (found in the student 
relation in pounds). ABDL does not support the retrieval of 
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computed values; however, this could easily have been 
implemented in the KFS module. We have chosen not to 
implement, since it does not represent a feature of SQL that 
is inherently relational. 

5. EiiiDiD^ting Duplicates 

The results of a SELECT query may contain 
duplicates. The elimination of duplicates is normally a 
high— cost operation and often unijiarrant ed . We_ do not 
provide such an option. SQL supports the elimination of 
duplicates through the use of the UNIQUE operator in the 
SELECT-cl ause. Thus, our implementation does not support 
the SQL UNIQUE operator. 

The work of Rollins CRef. 3: pp 82-831 has described 
the use of the SQL UNION operator in a query comprised of 
multiple SELECT constructs. Each SELECT construct 
translated to an equivalent ABDL RETRIEVE construct, and all 
are then processed by MBDS concurr ent 1 y . Rollins has 
assumed the capability to eliminate duplicates in the 
interface. In as much as such a facility is not provided by 
our implementation, we are not supporting the SQL UNION 
operator . 
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IHE kernel controller 



The kernel controller <KC) is the third module in the 
SQL language interface and is called by the language 
interface layer (LID when a new database is being created 
or when an existing database is being manipulated. In 
either situation the LIL first calls the kernel* mapping 
system (KNS) which performs the necessary SQL to ABDL 
translations. Then the KC is called to perform the task of 
controlling the submission of the ABDL transacti on (s) to the 
mul ti —backend database system CMBDS) for processing. If the 
transaction involves creating a new database or 
inserting, deleting or updating information in an existing 
database, control is returned to the LIL after MBDS 
processes the transaction. If the transaction involves a 
retrieval request, the KC sends the translated ABDL request 
to liBDS, receives the results back from MBDS, loads the 
results into a buffer and calls the kernel formatting system 
(KFS) to format the results a buffer at a time. After the 
last buffer is processed by the KFS the resulting table is 
displayed and control then returns to the LIL. 

□ne situation worth noting is the processing of an SQL 
nested-select request. An n— level SQL nested— sel ect is 
mapped to n corresponding ABDL retrieve requests. 
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Only the first ABDL retrieve (which corresponds. to the 
innermost select) is a f ul ly—f ormed request. All other 
ABDL retrieves which correspond to the outer-level selects 
are sent to the KC by the KMS as request templates- A 
request temgiate is an ABDL retrieve request with one 
unspecified attribute value. The KC must use the results 
obtained from the previous ABDL retrieve request (i.e., 
attribute values) and the request template to build the 
ne>?± ABDL request, i.e., the KC substitutes the retrieved 
attribute values for the unspecified attribute value in the 
request template. The processing of nested selects is 
managed by the KC. 

The procedures that make up the interface to the‘ KDS 
(i.e., MBDS) are contained in the test interface (TI) 
CRef. 81. To fully integrate the KC with the KDS (i.e., 
MBDS), the KC calls procedures which are defined in the TI. 
Due to upcoming hardware changes in the MBDS, v^e decide 
not to test the KC on-line with the TI- Our solution 
to this problem is to design the system exactly as if it 
is interfacing with the TI- However, for each call to a 
TI procedure we create a procedure stub that performs the 
same function as the actual TI procedure. The reader 
should realize that all interactions with the TI procedures 
described in the KC are actually made with these procedure 
stubs, rather than with the on-line TI procedures- 

In this section we discuss the processes performed by 
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the KC. This discussion is in two parts- First we 
examine the data structures relevant to the KC, which is 
followed by an examination of the procedures and functions 
found in the KC. Appendix D contains the design of 
our KC implementation, written in a system specification 
language. 

A- AN OVERVIEW OF THE KC DATA STRUCTURES 

In this section we will review the data structures 
mentioned in chapter 2, focusing on those structures that 
are accessed and used by the KC. The first data structure 
that is important ’*to the KC is the record type sql_info 
shown in Figure 15. The fields of sql_info contain all 
of the data structures relevant to the KC, but the KC 
only uses several of the fields. The first field of this 
record, curr_db , is a record which is used by the KC vshen 

struct sql_info 



struct 


curr _db_i nf o 


curr_db ; 


struct 


f i 1 e_i nf o 


file; 


struct 


tran_i nf o 


sql_tran; 


i nt 




oper at i on ; 


struct 


tran_inf o 


*abdl _tran ; 


i nt 




answer ; 


uni on 


kms_inf Q 


kms_data; 


uni on 


kf 5_i nf o 


kf s_data; 


uni on 


kc_i nf o 


kc_data; 


i nt 




error ; 


i nt 




subreq_stat ; 



Figure 15. The sql_info Data Structure. 
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interacting 


wi th 


MBDS. When the 


KC 


sends 


an ABDL 


transaction 


to 


MBDS -for execution. 


the 


current 


database 


name must be 


sent 


with the request. 


The 


current 


database 



name is stored in the curr_db record. 

The next field of the sql_info record type which the KC 
uses is operation- This fourth field of sql_info contains 
an integer that tells the KC what type of operation is to be 
performed. There are six possibly types of operations 
which correspond to the six operations supported by the KC. 
These operations are a database creation request, a retrieve 
request, a retr i eve— common request, a delete request, an 
insert request and an update request - 

The next field used by the KC is abdl_tran, which is a 
record of type tran_info, and is shown in Figure 16. The 
first two fields of tran_info are variant records which 
store information on ABDL requests- The ABDL requests are 
stored in a record of type ab_req_info, shown in Figure 17. 
Both first_req and curr_req initially contain the first ABDL 
request which is loaded into the data structure by the KMS. 

struct tran_info 
f 

union req_info 
union req_info 
int 

Figure 16- The tran_info Data Structure. 



f i rst_r eq ; 
curr_req ; 
no_req ; 
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*req ; 
rel _op ; 
*next_r eq ; 



struct ab_req_i nf o 
i 

char 
int 

struct ab_r el _i n-f o 

n 

j> 

Figure 17. The ab_req_in-fo Data Structure. 

The no_req tells the KC how many requests are in the linked 
list of the ab_req_info structure. There will normally only 
be one request in this list, u^iless an SQU nested 
sel'ect is being processed. In that case, the no_req will 
correspond to the number of levels that there are in the 
nested select. The first request will alv^ays.be a fully- 
formed ABDL request, while any additional requests will be 
ABDL request templates. The requests or request templates 
are stored, in the ab_req_info record. The -^req is a 
painter to a character string which contains either the 
request or the request template. The rel_op field 

informs the KC which type of relational operator is 

contained in the corr espondi ng request or request 

template. The eleven possible operators are IN, NOT IN, 
~=ANY, <=ANY, >=ANY, <ANY, >ANY , <=ALL, >=ALL, <ALL and 
>ALL- The *ne>it_req is a pointer which directs the KC to 
the next ABDL request. 

The next field of sql_info that the KC uses is kfs_data, 
which is a variant record into which the responses 

received from MBDS are stored. From this storage buffer 
the KFS extracts the data returned 
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from the KDS to be 



formated- This storage buffer is only used when we are 

processing SQL selects which have been mapped to ABDL 

retrieves. The results of the ABDL retrievals are 
loaded into the storage buffer- When the buffer is 

filled the KFS is called- The process of filling the 

buffer and calling KFS is repeated by the KC until all 

results from the retrieval have been processed- 

The next field used by the KS from the sql_info 

record type is kc_data. This field is a variant record 
which contains the record type kc_rel_info- This record 
type holds all of the information that is unique to the KX. 
This data structure is shown in Figure 18. The field 
file_status is a flag used to indicate the status of the 
current and future result files- Two files are necessary to 

struct kc rel info 



i nt 




file_status; 


struct 


max_i nf o 


max ; 


struct 


min_inf o 


min; 


int 




num_values_f f i le; 


int 




num_val ues_cf i 1 e ; 


struct 


nsel_res__inf o 


files; 


char 




*unf in_ret ; 


i nt 




beg_con j ; 


int 




end_con j ; 


i nt 




beg_aster i sk ; 


i nt 




end_aster i sk ; 


i nt 




req_len; 


int 




req_status; 


i nt 




curr_pos; 


int 




res len; 



Figure 18- The kc_rel_info Data Structure. 
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handle SQL nested selects- The f uture— resul ts file holds 
results from the current retrieve being processed by MODS, 
while the current— results file holds the results from the 
previous retrieve request, which are used to build the 
current retrieve request- The records max_info and 
min_info are identical data structures- Both structures 
allow for the storage of a character which indicates the 
data type of the attri bute— val ues , ^-e-, integers,/ fl oating 
poi'ht numbers or strings- Both structures also contain a 
variant record which is used for the storage of the 
respective maximum or minimum value encountered in the 
resultant records- The num_values_f f i le and num_val ues_cf i 1 e 
indicate the number of values stored in the future or 
current results file, respecti vel y . The record type of files 
is nsel _res_i nf o- The file field contains two identical 
records of type file_info- This record stores a file 
name and a file descriptor used for file manipulation in 
the C programming language- One record is for the 
curr ent-r esul ts file and the other is for the future- 
results file. 

The *unfin_ret is a character array used to store the 
request template sent to the KC by the KMS- The request 
template that is stored in the first field of the 
ab_req_info record type is loaded into unfin_ret. This 
transfer of the request template is necessary so that the 
f ul.l y-f ormed ABDL request that is constructed by the KC can 
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The 



be stored back into the *req field of ab_req_info, 
beg_con j , end_conj, beg_asterisk and end_asterisk are 
integer fields which store the positions they describe in 
the request template, i.e., (unf in^ret) . The conjunction is 
that portion of the request template which must be repeated 
as many times as necessary to hold the values returned 
from the previous inner — level request. The asterisks 

indicate where in that request the attribute-values must be 
placed. The field req_len holds the value of the maximum 
size in bytes of the fully— formed ABDL request that the KC 
builds and sends to the KDS. The req_len is calculated by 

• • t * 

the KC and is used for allocating storage for the fully- 
formed ABDL request which is constructed from the request 
tempi ate. 

The req_status is a flag used to indicate whether we 
are processing the first request or subsequent requests. 
Curr^pos is an integer-valued variable that is used to 
indicate our current position in the current-r equest file 
and that marks which attribute— value is the next one to be 
inserted into the request being constructed. The res_len 
is the last field in the record of type kc_rel_info and is 
an integer-valued variable which contains the length of the 
response buffer returned by the MBDS. This value is used to 
indicate when we have completed our movement through the 
response buffer. 

The final field used by the KC in the sql^info record 
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type is subreq_stat. This integer — valued variable is a flag 
used when the . KC is handling a nested select. The flag 
is set to indicate either that the last subrequest is 
being processed or an intermediate subrequest is being 
processed - 

B. KC PROCEDURES AND FUNCTIONS 

The KC makes use of a number of different procedures 
and functions to manage the transmission of the 
translated SQL queries (i.e.,ABDL requests) to the KDS. Not 
all of these procedures and functions will be discussed in 
detail. Instead, we hope to provide the reader with an 
overview of how the KC controls the submission of the 
various types of ABDL transactions to MBDS. 

1 - JiD® 

The procedure Kernel ^Control 1 er is called whenever 
the LIL has an ABDL transaction for the KC to process- 
This procedure provides the master control over all 
other procedures used in the KC. The first portion of 
this procedure initializes global pointers that are 
used throughout the KC. The other portion of the procedure 
is a case statement which calls different procedures based 
upon the type of ABDL transaction that is being processed. 
If a new database is being created, the procedure 
load_tables is called. If the transaction is a retrieve- 
common request, an insert request, a delete request or 
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an update request, the procedure rest_request_handl er 
is called. If • the transaction is a retrieve 
request, then the procedure sel ect_requests_handl er is 
called. If the transaction is none of the above, there 
is an error. An error message is generated and control is 
returned to the LIL. 

2- The Crfeat^gn of a New Database 

The ■ creation of a new l!atabase is the least 
dif'ficult transaction that the KC handles. The procedure 
load_tables is called by the KC and performs two functions. 
First, the test interface (TI) procedure dbl_template is 
called. This procedure is used to load the database- 
template file created by the KMS. Next the TI procedure 
dbl_dir_tbls is called- This procedure loads the 
database— descri ptor file- These two files represent the 
attr i bute— based metadata that is loaded into the KDS , i-e-, 
MBDS. After execution of these two procedures, load_tables 
returns control back to the kernel ^control 1 er which in turn 
returns control back to the LIL- 

3- loser t , Delete, Uodate and Retrieve— Common B® 9 y§sts 

Insert, delete, update and retr i eve— common requests 

are all handled in a similar fashion- For any of these four 
types of requests, the KMS sends the translated ABDL request 
to the KC for processing. The main task of the KC for these 
four categories of requests is to send the ABDL request to 
the KDS (MBDS) for processing- The KC handles these types 
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of requests by calling the procedure r est_requests_handl er 

which calls the procedure sql^execute. The procedure 

sql_execute controls the submission of ABDL requests to the 

KDS- To control the submission process the procedure 

sql_execute uses two TI procedures and the procedure 

sql _chk_r esponses_l ef t . In general, the procedure 

sql_execute sends the ABDL request to the KDS, waits for the 

last response to be returned fro^ the KDS and then takes 

action appropriate for the type of request submitted and the 

response received- For any of the request types sent to the 

KDS an error response might be received back* In this 
- 

situation, an error message is sent to the user. If an 
error response was not received, then the ABDL request was 
correctly processed- For insert, delete and update 

requests, the user is sent a message informing him that the 
operation has been successfully executed- For a retrieve- 
common request, the results returned by the KDS are sent to 
the KFS for formatting- Control then returns upward through 
the various procedures until it reaches the LIL- 
4 - 

ABDL retrieve requests are the other category 
of requests that the KC processes- The processing of 
retrieve requests is more complex than the other types of 
requests, since multiple retrieves (which correspond to SQL 
nested-selects) may need to be processed- The procedure 
sel ect _r equest s_handl er is called to process ABDL retrieve 
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requests. If a simple SQL select is being processed, then 
only one ABDL retrieve is generated by the KMS. If an SQL 
nested-select is being processed, then two or more ABDL 
retrieve requests are generated by the KMS. Only the first 
ABDL retrieve for an SQL nested-select is a complete ABDL 
retrieve. The remaining ABDL retrieves are actually ABDL 
request templates. An ' ABDL request template and the results 
of the previous retrieve are combined by the KC to build the 
f ul'l y— formed ABDL request. , The procedure * 

sel ect_requests_handl er manages both possible situations. 

First, the procedure sql_execute is called to process the 

^ t. •. ' 

initial fully— formed ABDL retrieve request. If this request 
is not an SOL nested-select, no other ABDL request templates 
remain. If ABDL request templates are left to process, then 
a loop is entered to process these retrieves. This loop is 
repeatedly executed until all ABDL request templates have 
been processed. 

An overviev-4 of the activities controlled by this 
loop is necessary to understand how the KC handles the SQL 
nested-select. One of the initial steps in the loop is a 
call to the procedure swap_files. This procedure obtains 
the results generated by the previous ABDL request (which 
are stored in the f uture-resul ts file by the procedure 
f i le_f uture_resul ts) and puts them into the current-r esul ts 
file, where they are used to build the next ABDL retrieve. 

The number of values in the curr ent-resul ts file (which has 
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been determined when the values are loaded into the file) is 



obtained for use in the procedure. After some 
initialization steps are executed an inner loop is 
encountered. This inner loop controls the actual building 
and executing of the current ABDL request template which 
corresponds to one of the outer — level SQL selects. 

The inner loop calls the procedure bui 1 d_request to 
produce the next fully-formed ABBL retrieve. Control in 
this procedure is branched based upon. which of the eleven 
possible SQL operators is in the current request. These 
eleven possible SQL operators result in four possible 
situations. For the operators <=ANY, <ANY, >=ALL and >ALL 
the procedure one_con junct i on is called with the maximum 
value of the results in the current results file passed as a 
parameter. (The maximum and minimum values were calculated 
by the procedure f i 1 e^f uture_resul ts when the values were 
loaded into the f utur e-resui ts file.) For the operators 
>=ANY, ]>ANY, <=ALL and <ALL the procedure one_con juncti on is 
al so called, this time with the minimum value of the results 
in the current— resul ts file passed as a parameter. For the 
I^4 and ^^=ANY operators the procedure n_con juncti on is 
called- For the NOT IN operator the procedure 
not_in_con juncti on is called. These three conjunction 
procedures all produce one or more fully— formed ABDL 
retrieves using the request template. The inner loop then 
calls sql_execute to process the ABDL retrieve. The inner 
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loop concludes with some steps that prepare for the next 
retrieve- The inner loop repeats as long as there are values 
left in the current-resul ts file and the procedure 
one_con junction has .not been called. The outer loop then 
sets up for the next ABDL retrieve and concludes- A more 
detailed example of how the procedures n_con juncti on , 
not_in_con juncti on , and one_con juncti on work will be covered 
in the following two sections. ^ 

a. The N_con juncti on Procedure 

The procedure n_con juncti on uses the ABDL 
request template and the values from the previous ABDL 
retrieve stored in the current-r esul ts file to build a 
fully-formed ABDL retrieve. The ABDL request template 
contains a portion of the ABDL request which we have labeled 
the conjunction. This conjunction portion of the request 
template is bounded by the first set of outermost 
parenthesis in those requests handled by the procedure 
n_con juncti on . This conjunction contains a number of 
predicates that are "and'ed" together. A educate is a 
triple consisting of an attribute name, followed by a 
relational operator (i.e., >, >=, ...) followed by an 
attribute value- Recall that in an earlier discussion we 
stated that the request template contains an unspecified 
attr i bute— val ue- In our current terminology, this means 
that a predicate in the conjunction of the request template 
has an unspecified attribute- value. To mark this value 
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within the request template character string, we use a 
series o-f asterisks, where the number o-f asterisks 
corresponds to the maximum attribute-value length. The 
procedure n_con juncti on uses the conjunction portion 
repeatedly with each conjunction having a different value 
from the results file inserted in place of the asterisks. 
The conjunctions are then "or'ed" together to form the 
fully— formed ABDL retrieve. ' 

We have chosen not to allow an unlimited 
number o-f conjunctions to be joined together into one ABDL 
request- Rather we have created an upper limit on the 
maximum number o-f conjunctions that may be joined together 
into a single ABDL retrieve- We call this constant 
NUM_CONJ. Thus, assuming we have NUM_CONJ set to ten, 
only ten conjunctions can be linked together in one ABDL 
retrieve. This means only ten values from the current- 
results file can be loaded into the retrieve, one per 
conjunction. If there are more than ten results in the 
current-resul ts file, then more than one ABDL retrieve 
must be built. This situation necessitates the inner 
loop discussed in the procedure sel ect_r equests_handl er - 

We now look at an example, to fully understand 
the operation of the procedure n_con junction- We will build 
the outer ABDL retrieve for the nested select presented 
presented in Chapter IV. The SQL nested select is as 
follows: 
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SELECT name, age 
FROM student 
WHERE name IN 

( SELECT name 

FROM faculty ) 

This query would find the name and age of all students who 
are also a member of the faculty. The KMS maps the SQL 
nested— sel ect to the following two ABDL retrieves. 

> C RETRIEVE (TEMPLATE = FACULTY) (NAME) 1 

C RETRIEVE ( (TEMPLATE = STUDENT) and 

(NAME = ) (NAME, A6E) 1 

The -first ABDL retrieve which corresponds to the innermost 
SDL request is executed by the procedure sql_execute. The 
results o-f this retrieve will be names of personnel on the 
faculty are stored in the curren t-resul ts file. We assume 
that there are three names returned and that they are 
Demurjian, Mack and Kloepping. 

The procedure n_con junct i on marks several 

locations in the request template the first time it is 
called for a particular SQL request. The procedure stores 
the location of the beginning and the end of the conjunction 
and the location of the first and last asterisk which 
delineates the unspecified attribute-value. In the previous 
example the conjunction is as follows: 
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((TEMPLATE = STUDENT) and (NAME 



***********) ) 



This conjunction is to be used three times to construct the 
f ul 1 y— formed ABDL retrieve- The ABDL retrieve built by the 
procedure n_con juncti on is shown in Figure 19. 

If there had been more than NUM_CONJ names in 
the current-resul ts file, then more than one f ul 1 y*-f ormed 
ABDL retrieve would have to be generated for the 
corresponding SQL select. The first NUM_CONJ names would 
have to be inserted into predicates that are "or'ed” 
together. Another ’.ABDL retrieve would then be built using 
the next NUM_CONJ names from the curr ent-resul ts fils- ABDL 
retrieves would continue to be built until all names in the 
current-r esul ts file have been exhausted- 

b. The Procedures Not_i n_con juncti on and 

One_con juncti on 

The procedure not_i n_con juncti on operates in a 
similar fashion to the procedure n_con juncti on - The major 
difference is that the conjunction portion of the request 

C RETRIEVE (((TEMPLATE = STUDENT) and (NAME = DEMURJIAN)) or 

((TEMPLATE = STUDENT) and (NAME = MACK)) or 

((TEMPLATE = STUDENT) and (NAME = KLOEPPING) ) ) 

(NAME, AGE) 1 

Figure 19. The ABDL Retrieve Generated by the 
Procedure N_con juncti on- 
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template is smaller and the conjunctions are 



and 'ed'* 



together rather than “or'ed” together. Suppose that we 
replace the IN operator in the previous SDL nested-select 
query with the NOT IN operator. The • resul ti ng SQL query 
would find the name and ages of all students who are not 
members of the faculty. The first ABDL retrieve would be 
identical to the first ABDL retrieve in the last example. 
The second ABDL retrieve would now bfs as follows: 

C RETRIEVE ( (TEMPLATE = STUDENT) and 

(NAME ~= ***********) (NAME, AGE) 1 

The conjunction portion for the procedure not_in_con juncti on 
would be as follows: 

((TEMPLATE = STUDENT) and (NAME **********-«•* ) ) 

The procedure not_i n_con juncti on inserts the names from the 
current— resul ts file into this conjunction and "ands" the 
conjunctions together. The fully-formed ABDL retrieve is 
shown in Figure 20- 
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C RETRIEVE ((TEMPLATE = STUDENT) and (NAME DEMURJIAN) 
and (NAME MACK) and (NAME ~= KLOEPPING) ) 
(NAME, AGE) 1 

Figure 20, The ABDL Retrieve Generated by the 
Procedure Not_i n_con juncti on . 

It there are more than NUM_CONJ names in the current— resul ts 
tile, then, as betore, additional ABDL retrieves would be 
generated. The multiple ABDL retrieves to be generated are 
hapdled identically as they the .procedure 

n_cbn juncti on - 

The procedure one^con juncti on manages a simpler 
situation. For the procedure one_con juncti on/ we are also 
sent an ABDL request template by the KMS. In these type 
situations all that must be done is to replace the asterisks 
with the minimum or maximum value that has been passed into 
the procedure as a parameter. Thus, the procedure 

□ne_con juncti on simply removes the asterisks and inserts the 
passed in value in its place. It is only necessary for this 
single ABDL retrieve to be generated once- For example, 
suppose we are processing the following SQL nested-sel ect - 

SELECT name, age 
FROM student 
WHERE age <ALL 

( SELECT age 
FROM faculty ) 

This SQL query will retrieve the names and ages of all 
students that have an age less than all the faculty ages. 
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In other words, this request -finds the names and ages o-f all 
students who have an age less than that o-f the youngest 
-faculty member. The KMS maps the SQL nested-select to the 
-following two ABDL retrieves. 

C RETRIEVE (TEMPLATE = FACULTY) (AGE) 3 

C RETRIEVE ( (TEMPLATE = STUDENT) and 

(AGE <= ***) ) (NAME, AGE) 3 

•f 

Assume the -first retrieve results in -the ages o-f 54, 43, 37 

and 39 being returned. Since the SQL operator is <ALL, the 
minimum age i% passed to the procedure one_con junct i on . The 
-f ul 1 y— formed ABDL retrieve that the procedure 

one_con juncti on generates is shown in Figure 21. 

C RETRIEVE (TEMPLATE - FACULTY) (AGE) 3 

C RETRIEVE ( (TEMPLATE = STUDENT) and 

(AGE <= *■**)) (NAME, AGE) 3 

Figure 21. The ABDL Retrieve Generated by the 
Procedure One_con junct i on . 



sa 



VI- IHE KERNEL FORMATTING SYSTEM (KFS) 



The KFS is the fourth module in the SQL language 
interface and is called from the kernel controller (KC) 
when the KC has obtained the final results from MBDS. 
The results are passed to the KFS in one or more character 
buffers, called response buffers. If,'there is more -than one 
re^onse buffer, the KC calls the KFS again for each 
buffer. The KFS manipulates the contents of these 
buffer <s) to create an image of an SQL results table- This 
table is formated in a file on each call to the KF5- 
Hencs, this allows the user to view the results of his 
queries as if he is working with an SQL-type database 
system. The following example illustrates this process: 

1. The user issues a query: 

SELECT NAME, AGE 
FROM EMPLOYEE 
WHERE AGE < 30 

2. The query is processed by all modules of the 
interface. Eventually, the KC receives the final re- 
sul ts. 

3- The KC calls the KFS for each response buffer. 

4. The KFS uses the response buffer to create the output 
table- For illustrative purposes, suppose that the 
response buffer contains the following data: 

NAME JOHN AGE 29 NAME STEVE AGE 26 

5. The KFS displays the appropriate SQL output table: 
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i EMPLOYEE I 

1 1 


1 

; NAME ; 


1 

AGE i 


1 JOHN i 


29 ! 


! STEVE 


26 ! 



It is important for the reader to note that the table 
actually consists of two parts- The first part is the 
table heading and column headings. 0 In the example above 
thi^s is the attribute called NAME followed by the 
attribute AGE- These are column headings- The table 
heading consists of the name of the relation, EMPLOYEE- The 
second part is instances of these attribute names or 
results, i-e-, attribute values- In our example, JOHN and 
STEVE are results pertaining to the attribute NAME; while 
29 and 26 are the results pertaining to the attribute AGE- 

A- THE KFS PROCESS 

In this section we discuss the processes that the KFS 
uses to create an SQL output table- We present these 
processes in the same sequence as they are performed by 
the KFS- We begin this discussion, however, with an 
overview of those data structures unique to the KFS- This 
overview can facilitate our understanding of the C code that 
constitutes this module- 
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1 . 



of. the !<FS Data Structures 
The KFS utilizes, for the most part-, just three of 
the structures defined in the language interface. The first 



of these, shown in 


Figure 22 


, i s a 


record 


that 


contai ns 


inf or mat i on 


needed 


by the 


KFS to 


process 


the 


resul ts. 


The first 


■field 


in this 


record , 


response 


, contains the 


result from 


MBDS 


which is 


loaded by 


the KC 


just 


prior to 



calling the KFS. The second fiel^J, curr_pos, tells the 
KFS where it is in the response buffer. This helps the KFS 
maintain a correct orientation in the response buffer- The 
next field, res_len, indicates the length of the 
response buffer- This value is mostly used as a 
halting condition. For instance, the KFS continues to 
pull characters out of the buffer while some inde:< is less 
than or equal to the res_len. The next field, form_data, is 
a record and contains information about the output table 
heading. This record will be discussed in the following 

struct kfs rel info 



char 




■^response; 


int 




curr_pos; 


i nt 




r es_l en ; 


struct 


tabl e_header_i nf o 


f orm_data; 


struct 


f i 1 e_i nf o 


o_f i 1 e; 


int 




status; 


struct 


rattr_node 


*f i rst_rel ; 


struct 


rattr_node 


-«-sec_rel ; 


lure 22. 


The kfs_rel_info Data Structure. 
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paragraph. The fifth field, o_file, isr also a record. The 
o_file record contains the file name and the file 

identifier of the file that the KFS is building the 

\ 

output table in. This is needed by the C language to open 
the output file for read, write, or append access. The 

next field, status, acts as a flag. If this is the first 
time the KFS is entered for a particular set of response 
buffers and, therefore, a ‘ particular user, then this field 
contains a value of FIRSTIME. This tells the KFS that it 
needs to initialize values and set various structures for 
subsequent processing. The status is changed Rafter this 
is completed so that this initialization is not to be 

repeated for subsequent calls to the KFS for the same set 
of responses. The seventh field, first_rel, is a pointer 
to a list of attributes for the relation being currently 
processed. The data pertaining to this list can be 

considered the schema of the current relation- The 

specific data that is needed from the schema is the 
maximum size (in terms of the maximum attribute length) 
that the attribute named in this structure can possibly 
take on- This information is needed so that the correct 

column width for each attribute can be built into the output 



table. The final 


field is used 


for 


the same 


reasons 


discussed above. 


but is needed 


to 


i mpl ement 


the JOIN 



command - 
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The second structure the KFS uses extensively is 
also a record and is called table_header_int o and is 
depicted in Figure 23- The purpose o-f this record is to 
provide in-formation about the heading o-f the output table. 



The -first 


-field. 


table_width, is 


an 


integer value 


containing 


the 


width of the output 


table- 


This 


i n-f ormati on 


tells 


us whether or not 


the 


table can 


fit 


within one 


hori z 


ontal screen width- 


This serves as 


the 


basis -for some o-f 


our logic in the KFS 


and 


is discussed 


in 



detail in the next section- The next -field, first_ent, 

points to another record that contains in-formation about 

the -first attribute name in the heading o-f the output 
table. The last -field is the same as the previous one 

except that it points to the the current tabl e_entry_i n-f o 
record that the KFS is now working with- 

The third data structure, like the previous two, 
is also a record- This record maintains all of the 

information needed to correctly position attribute names 
in the heading of the output table. It also contains 



struct tabl e_header_inf o 

r 

’v. 

int table_width; 

struct tabl e_entry_i nf o *first_ent; 

struct tabl e_entry_inf o *curr_ent; 



Figure 23- The table_header_inf o Data Structure- 
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the information needed to correctly position the results 
under the appropriate headings. The first field, shown 
in Figure 24, is a character array containing the name of 
an attribute that is used as part of the output table 
heading. The second field is an integer value containing 
the length of the stored attribute name. This value is 
compared with the next field to determine the actual 
width of the column 'for thii particular attribute. 
The" next field, val_len, contains ;an integer value that 
is the maximum size a result of this attribute type can 
possibly take on. The fourth* field, col_len, holds the 
maximum of the two previous fields and is the actual 
width of a column for a particular attribute in the output 
table. The last field, next, is just a pointer to the 
next record of this type. Using this field the KFS can 
move from one record to another record and create the 
correct heading until it hits a NULL record. 



str uct tabl e_entry__i nf o 



char 
i nt 
i nt 
i nt 

struct 



tabl e_entry_i nf o 



attr C ANl ength + 11 
name_l en ; 
val _1 en ; 
col _1 en ; 

*nex t ; 



Figure 24. 



The tabl e__entry_inf o Data Structure. 
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2- KFS Procedures and Functi_ons 

The KFS makes use o-f a number of procedures and 
functions to create a finished SQL results table from a 
response buffer • We do not discuss all of these in 
detail. Rather, we do provide an overview of the more 
salient ones. We hope the reader may gain a more rounded 
appreciation of our effort from this discussion. 

a. Initializing \ - 
Whenever the KFS is called, the initialization 

is required. This process basically involves setting 
values in the KFS data structures. For instance, the 
curr_pos is set to the first character in the response 
buffer. The initialization procedure also opens the output 
file in which the SQL table is to be created for the proper 
access- When the KFS is called for the first time, this 
file, is opened for write access- Subsequent calls to the 
KFS for the same set of queries open this file for append 
access- This is done so that we do not overwrite data 
already in this file- The appropriate actions taken by the 
initialization routine is controlled by the value in the 
status- This value is updated by this routine after the 
f i rst cal 1 . 

b. Filling the Table Headings 

The first time that the KFS is called the 
response buffer is scanned so that information may be 
gathered about the attribute names of the results. This 
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information is used by the KFS to create the header part of 
the output table- 

This routine begins by reading the first 
attribute from the response buffer- The string length 
of this attribute is determined next; followed by a 
trace through the list of attributes in the schema of 
the current relation- The trace is completed when this 
attribute is 'found in the schema- At-^this point, the maximum 
si^e that a value of this attribute type may take on can be 
determined- This information is stored in val_len. The 
maximum of val_len and the string length of the attribute 
is then calculated and placed in col_len- This value 
represents the actual column width this attribute will 
have in the output table. The unwary reader may miss the 
importance of this step- It is easy to assume that the 
only value needed is val_len- However, . let's assume 
there is an attribute called ZIP_CODE- The maximum number 
of characters this attribute may have is five digits. If 
we do not consider the string length of this attribute 
name, then the column size would be just five characters 
wide and ZIP_CQDE would appear as ZIP_C in the heading. 

This process of reading the next attribute is 
iterated until either it has cycled through a series of 
unique attribute names or it has processed all the 
attributes in the response buffer- 
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c. Creating the Table in the Output File 

This part of the KFS can be considered the 
workhorse oT the module. The previous two processes 
are instrumental in manipulating data structures and 



setting variable 


values so that this process may fulfill the 


intended mission 


of the KFS. Therefore, we discuss some 


o-f the issues 


we have struggled with while designing this 


part o-f the KFS. 


The two most important issues arei 


1'. How shoul d 


the table appear to the user? 


2. How should 


the table be stored internally, i.e.. 



should it be in a file, a character array, or dis- 
played immediately to the user? 

Our problem has been that we have had no 

concrete examples of what an SQL table should look like. 

Should the headings be centered within the columns, 

with the results centered under these headings? We 



didn't know. We 


finally decided upon a convention that 


would facilitate 


programming. Hence, we 1 eft- just i f i ed both 


the headings and 


the results v-jith blanks added at the end of 


each to insure 


proper spacing within the columns. As it 


turned out, this 


is also the way Date CRef. 17: pp. 117-1423 



presents his examples. 



The 


second issue has posed a problem. Qur 


initial design 


has called for building the table in a 


character array. 


The only other alternative considered at 


this time has 


been to immediately put the table on the 



screen as results are being passed to the KFS- This idea 
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is dismissed, however, when we have realized the 
di f "f i cul ti es o-f trying to build a table on the -fly. In a 
similar -fashion, ^ the idea o-f building the table in a 
character array is also dismissed. There is no way -for 
us to predetermine the size o-f this array. We have 
thought that it is uneconomical to allocate a huge array 
to cover all possible table sizes- There is also the 
problem o-f moving around in the krray. This = indexing 
problem created a preponderance o-f C qode- 

Our only other alternative is to build the table 
in a -file- This method has proved very easy to do. The 
operating system maintains position within the file, so, 
there is no indexing problem. In addition, there is more 
economical use of* the computer's resources, since the file 
is only as big as necessary- Hence, we have opted to build 
the table in a file- 

With these issues resolved, the 
implementation of this process has been str ai ghtf orwar d - 
First, the headings are built in the output file- This 
is done only the first time the KFS is called- Next, the 
attribute values are pulled from the response buffer and 
placed 1 eft- just i f i ed under the corr espondi ng 
attribute. Then, the process is iterated until the 



98 



response buffer is exhausted. Subsequent calls to the KFS 
for the same set of queries cause results to be appended 
to the table in the file. 

d. Displaying the Table 

The KFS displays the SQL table to the user when 
all response buffers have been processed. This occurs 
when a special signal is detected in the last buffer in 
conjunction with the setting of^a status signifying the 



last sub_request 


of a 


nested select. 


; An initial 


problem we 


have had with 


this 


process has 


been how to 


display a 



table more than twenty-four lines long. A unique 

procedure, patterned after the 'more' facility in UNIX 
CRef- 183, is developed. This function, when first 
called, displays the first twenty-two lines of the SQL 
table and then prompts the user. The user can choose from 
a number of options- * For instance, the user can have 

another screen— full of results displayed, or the user can 
displ ay some number of lines less than tvNenty— two, or the 
user can even terminate the current menu of the language 
interface. Our intent is to make viewing the results as 

convenient as passible to the user, 
e. Cleaning Up 

Before leaving the KFS, the data structures 
used to create the SQL table are freed. This ensures that 
the resources are available to process other queries. 
Additionally, the status field is updated to FIRSTIME. This 
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places the KFS in the correct state to process subsequent 
queries correctly . 

B. A LIMITATION OF THE KFS 

Although we have tried to make the KFS as general 
as possible with regard to creating and displaying SQL 
tables, there is one facility we have deliberately 
neglected to incorporate. ' This is the ability to display 
tables VMith widths greater than eighty columns. Since 

our intent is to only show that the interface could 
indeed be developed, we have decided that the programming 
effort required'to provide this facility is too costly for 
the benefits derived. However, this is not to imply that 
this facility is not useful or needed. As a matter of 
fact, we have intentionally designed the KFS for the easy 
insertion of this code when it is developed. 
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VII. CONCLUSION 



In this thesis, we have presented the specification 
and implementation of a SQL language interface. This is 
one of four language interfaces that the mul ti— 1 ingual 
database system will support. In other words, the multi- 
lingual database system will be able^to execute transactions 
written in four well-known and important data languages, 
namely, SQL, DL/I, Daplex, and CODASYL. SQL is of course 
the well-known relational data language provided by, for 
example, IBM SQL/Data System- In our case, we support SQL 
transactions with our language interface by way of LIL, KC, 
KMS, and KFS in place of SQL/Data System. A related thesis 
by Benson and Wentz CRef- 191 examines, the specification 
and implementation of the DL/I language interface. Tv-^o 
other theses on CODASYL and Daplex respectively are under 
way- This work is part of ongoing research being 
conducted at the Laboratory of Database Systems Research, 
Naval Postgraduate School, Monterey, California. 

The need to provide an alternative to the development 
of separate stand-alone database systems for specific data 
language models has been the motivation for this research. 
In this regard, we have first demonstrated the feasibility 
of a mul t i — 1 i ngual database system (MLDS) by showing how a 
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so-ftware SQL language interface can be constructed. 
Specific contributions of this thesis include the 
development of useful algorithms and the implementation 
of SQL operations such as; nested retrieval, join 
operations, retrieval of grouped attributes, and updating 
multiple fields. In addition, we have developed a LIL that 
is virtually reusable. With minor modifications the LIL can 
be used with the other language interfaces. As a matter of 
fact, it has been recently modified for the DL/I language 
interface. Our design of the generic data structures is 
also noteworthy. Because of our extensive utilization of 
unions (i.e., variant records), the other language 
interfaces can use our generic data structures. We have 
extended the work of Macy CRef. 21 and Rollins CRef. 31 by 
specifying and implementing the algorithms for the language 
interface. In addition, we have also provided a general 
organizational description of a MLDS. 

A major goal has been to design a SQL-to-MBDS interface 
■without requiring any change be made to MBDS or ABDL. O'ur 
implementation may be completely resident on a host 
computer or the controller. All SQL transactions are 
performed in the SQL interface. MBDS continues to 
receive and process transactions written in the unaltered 
syntax of ABDL. In addition, our implementation has not 
required any change to the syntax of SQL. The interface is 
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completely transparent to the SQL user as well as to the 
MBDL. 

In retrospect, our 1 evel — by—1 evel , top-down 
approach to the design o-f the interface has been a good 
choice- This implementation methodology has been the most 
familiar to us and proved to be relatively efficient in 
time. In addition, this approach permits follow-on 
programmers to easily maintain and^modify (when necessary) 
the code- Subsequently, they will know exactly where vge 
have stopped and where they should begin because we have 
included many^ of the lower-level stubs. Hence, it is an 
easy task of filling in these stubs with code- 

We have shown that a SQL interface can be implemented 
as part of a MLDS- We have provided a software 
structure to facilitate this interface, and we have 
developed the actual code for implementation. The next 
step is to implement the other interfaces- When these 
are complete, the system needs to be tested as a VMhole to 
determine how efficient, effective, and responsive it is 
to users' needs. The results may be the impetus for a new 
direction in database system research and development. 
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APPENDIX A 



SCHEMATIC OF THE DATA STRUCTURES 



The purpose of this appendix is to present a pictorial 
of data structures used in the SQL language interface. 
Since the code used for the thesis was the C programming 
language, the diagram makes use of its constructs just 
as the code does. Groups of related items are known as 
structures in C, and it is easy to see from the diagram 
that the structures break down intojmore detai 1 ed wor kabl e 
structures. There are two major parts of this appendix. In 
Figure 25 we present the relational database schema data 
structures that were discussed in Chapter 2. In Figure 
26 we present the user data structures. 

In the diagrams an arrow indicates that the field 
is a pointer to a structure. Each of the fields of such 
a structure is preceded by a small arrow to indicate that 
indeed a pointer from another structure is referencing 
the field. An example of this is the field si_ddl_files 
of the SDL_INFQ structure in Figure 26 on page 113. The 
field si_ddl_files points to a structure of type DDL_INFO. 
This is especially useful when writing or tracing long paths 
through the user data structure. 

On the other hand, bracket lines are used to indicate 
when a field of a structure is also a structure. The 
bracket lines are drawn from the "parent'* field to the 
"child’* structure. A period is placed in front of the 
bracketed structure's fields to indicate this fact. An 
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example o-f this is the si_sql_tran field of the SQL_INFQ 
structure in Figure 26 on page 112- The field si_sql_tran 
is a structure of type TRAN_INFO- The bracket lines and the 
periods indicate this- 

We note that the diagram has a few instances of UNIONS. 
A union is a construct that allows the user to connect 
different structure types, specified by the union 
structure, to a common structure,^ i.e., unions'-are also 
ret-ered to as variant records. Since the mul ti -1 i ngual 
database system is to support the mapping of multiple 
langtjages, many portions of the user structure will be the 
same for any language used. However, the union construct 
allows for the parts that must change between language 
interfaces so that the common data structures can be adapted 
to be useful to all of the language interfaces. 



105 







106 




107 



')]ve 







108 




109 



Figure 26. Phe User Structures. 
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Fifrure 26 . (Continued) 
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APPENDIX B - THE LIL PROGR.AM SPECIFICATIONS 



module SQL- INTERFACE 

db-list : list; /* list of existing relational schemas */ 
head-db-list-ptr: ptr; /* ptr to head of the relational schema list */ 
current-ptr: ptr; /* ptr to the current db schema in the list */ 
follow-ptr: ptr; /* ptr to the previous db schema in the list */ 
db-id : string; /* string that identifies current db in use */ 

proc LANCUACE.INTERFACE-LAYERO; ^ 

/* This proc allows the user to interface with the system. */ 

-:/* Input and output: user SQL requests ^ */ 

stop : int; /* boolean flag */ 

answer: char; /* user answers to terminal prompts */ 

perform SQL-INIT(); 
stop = ’false’; 
while (not stop) do 

/* allow user choice of several processing operations */ 

print (’’Enter type of operation desired”); 

print (” (1) - load new database”); 

print (” (p) - process existing database”); 

print (” (x) - return to the to operating system”); 

read (answer); 

case (answer) of 

’1’: /* user desires to load a new database */ 
perform LOAD-NEW(); 

’p’: /* user desires to process an existing database */ 
perform PROCESS-OLD(); 

’x’: /* user desires to exit to the operating system j 
/* database list must be saved back to a file */ 
store-free-db-list(head-db-list, db-list); 
stop = ’true’; 
exit(); 

default: /* user did not select a valid choice from the menu 
print (’’Error - invalid operation selected”); 
print (’’Please pick again”)’ 
end-case; 

/* return to main menu */ 
end-while; 

end-proc; 
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proc SQL-INITO; 
end-proc; 



proc LOAD-NEW(); 

/* This proc accomplishes the following: */ 

/* (1) determines if the new database name already exists. */ 

/* (2) adds a new header node to the list of schemas, */ 

/* (3) determines the user input mode (file/terminal), */ 

/* (4) reads the user input and forwards it to the parser, and */ 
/* (5) calls the routine that builds the template/descriptor files */ 

answer: int; /* user answer to terminal prompts */ 

'-more-input: int; /* boolean flag */ 
proceed: int; /* boolean flag */ 
stop : int; /* boolean flag */ 

db-list-ptr: ptr; /* pointer to the current database */ 
req-str: str; ^ /* single create in SQL form */ 

ptr-abdl-list: ptr; ptr to a list of ABDL queries (nil for this proc)*/ 
tfid, dfid: ptr; /* pointers to the template and descriptor files */ 



/* prompt user for name of new database */ 
print (’’Enter name of database”); 
readstr (db-id); 
db-list-ptr = head-db-list-ptr; 

stop = ’false’; 
while (not stop) do 

/* determine if new database name already exists */ 
/* by traversing list of relational db schemas */ 
if (db-list-ptr, db-id = existing db) then 
print (’’Error - db name already exists”); 
print (’’Please reenter db name”); 
readstr (db-id); 
db-lrst-ptr = head-db-list-ptr; 
end-if; 
else 

if (db-list-ptr — 1 = ’nil’) then 
stop = ’true’; 
else 

/* increment to next database */ 
db-list-ptr = db-list-ptr -r 1; 
end-else; 

end-while; 
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/* continue - user input a valid ’new’ database name */ 

/* add new header node to the list of schemas and fill-in db n^me */ 

/* append new header node to db-list */ 
create-new-db(db-id); 

/* the KMS takes the SQL creates and builds a new list of relations */ 
/* for the new database. After all of the creates have been processed */ 

the template and descriptor files are constructed by traversing */ 
/* the new database definition (schema). */ 

more-input = ’true’; 
while (more-input) do 
/* determine user’s mode of input */■. 
print (’’Enter mode of input desired”); 
f5rint (” (f) - read in a group of creates from a file”.); 

print (” (t) - read in a single create from the terminal”); 

print (” (x) - return to the main menu”); 

read (answer); 

- • . » 

case (answer) of 

T : j* user input is from a file */ 

perform READ-TRANSACTI0N-FILE(); 
perform CREATES-TO-KMS(); 
perform FREE-REQUESTS(); 
perform BUILD-DDL-FILES(); 
perform KERNEL-CONTROLLER(); 

’t’; /* user input is from the terminal */ 
perform READ-TERMINAL(); 
perform CREATES-TO-KMS(); 
perform FREE-REQUESTS(); 
perform BUILD-DDL-FILES(); 
perform KERNEL-CONTROLLER(); 

’x’: /* exit back to LIL */ 
more-input = ’false’; 

default: /* user did not select a valid choice from the menu */ 
print ("Error - invalid input mode selected"); 
print ("Please pick again"); 
end-case; 
end-while; 

end proc; 
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proc PROCESS-OLDO; 

/* This proc accomplishes the following: */ 

/* (1) determines if the database name already exists, */ 
/* (2) determines the user input mode (file/ terminal), */ 
(3) reads the user input and forwards it to the parser */ 



answer: int; 
found: int; 
more-input: int: 
proceed: int; 
db-list-ptr: ptr; 
req-str: str; 
ptr-abdl-list: ptr 
tfid, dfid: ptr; 



/* user answer to terminal prompts */ 

/* boolean flag to determine if db name is found */ 
/* boolean flag to return user to LIL j 
/* boolean flag to return user to mode menu */ 

/* pointer to the current database */ 

/* single query in SQL form */ 

; /* pointer to a list of queries in^ABDL form */ 

/* pointers to the template and descriptor files */ 



/* prompt user for name of existing database */ 

print (”Enter name of database'’); 

readstr (db-id); 

db-list-ptr = head-db-list-ptr; . 



found = ’false’; 
while (not found) do 

/* determine if database name does exist */ 

/* by traversing list of relational schemas */ 
if (db-id = existing db) then 
found = ’true’; 
end-if; 
else 

db-list-ptr = db-list-ptr ^ 1; 

/* error condition causes end of list(’nil’) to be reached */ 
if (db-list-ptr = ’nil’) then 
print (’’Error - db name does not exist”); 
print (’’Please reenter valid db name”); 
readstr (db-id); 
db-list-ptr = head-db-list-ptr; 
end-if; 



end-else; 

end-while; 
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/* continue - user input a valid existing database name */ 

/* determine user’s mode of input */ 

more-input = ’true’; 
while (more-input) do 
print (’’Enter mode of input desired”): 
print (” (f) - read in a group of queries from a file”); 

print (” (t) - read in a single query from the terminal”); 

print (” (x) - return to the previous menu”); 

read (answer); 

case (answer) of 

’f : /* user input is from a file j ^ 

perform READ-TRANSACTlON-FILE(); " 
perform QUERIES-TO-KMS(): 
perform FREE-REQUESTS(); 

’t’: user input is from the terminal */ 

perform READ.-TERMINAL(); 
perform QUERIES-TO-KMS(); 
perform FREE-REQUESTS(); 

’x’: user wishes to return to LIL menu j 

more-input = ’false’; 

default: /* user did not select a valid choice from the menu * j 
print (’’Error - invalid input mode selected”); 
print (’’Please pick again”); 
end-case; 

end-while; 

end-proc; 
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proc READ-TRANSACTION-FILEO; 

/* This routine opens a create/query file and reads the requests j 
/* into the request list. If open file fails, loop until valid ! 
file entered */ 

while (not open file) do 
print (^’Filename does not exist”); 
print (”Please reenter a valid filename”); 
readstr ( file); 
end-while; 



READ-FILEO; 

end-proc; 






proc READ-F1LE(); 

/* This routine reads transactions from either a file or the */ 

/* terminal into the user’s request list structure so that */ 

/* each request may be sent to the KERNEL-MAPPING-SYSTEM. */ 

end-proc; 



proc READ-TERxMINAL(); 

/*" This routine substitutes the STD IN filename for the read */ 

/* command so that input may be intercepted from the terminal */ 

end-proc; 



proc CREATES-TO-KMSO; 

j'^ This routine sends the request list of creates one by one */ 

'r to the KERNAL-MAPPING-SYSTEM V 

while (more-creates) do 
KERNAL-MAPPING-SYSTEMO; 
end-while; 

end-proc; 
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proc QUERIES-TO-KMSO; 

/* This routine causes the queries to be listed to the screen. */ 

/* The selection menu is then displayed allowing any of the */ 
/* queries to be executed. */ 

perform LIST.QUERIES(); 
proceed = ’true’; 
while (proceed) do 

print ("Pick the number or letter of the action desired"); 
print (" (num) - execute one of the preceding queries"); 

print (" (d) - redisplay the file of queries"); 

print (" (x). - return to the previous menu"); 

read (answer); *. 

c^e (answer) of 

'num’ : /* execute one of the queries * / 
traverse query list to correct query; 
perform KERNAL-MAPPING-SYSTEM(): 
perform KERNEL-CONTROLLERO; 

’d’ : /* redisplay queries */ 

perform LIST-QUERIES(); 

’x’ : /* exit to mode menu 

proceed = ’false’; 

default : /* user did not select a valid choice from the menu */ 
print (" Error - invalid option selected"); 
print (" Please pick again"); 
end-case; 

end-while; 

end-proc; 

end-module; 
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APPENDIX C . THE KMS PROGRAM SPECIFICATIONS 



module KMS () 
perform parser() 
end-module KMS 



proc yyparse () . ^ 

-l/* This proc accomplishes the following : ^ */ 

/* (l) parses the SQL input requests and maps them to appropriate */ 
j* abdl requests, using LEX and YACC to build proc yyparse(). */ 
/* (2) builds the relational schema, when loading a new database. */ 

/* (3) checks for validity of relation and attribute names within j- 
/* the given db‘ schema, when processing requests against an */ 
j'^ existing database. */ 



%{ 



%} 



list: tgt-list /* list of attribute names */ 

list; templates /* relation name(s) */ 

list; insert-list /’*' list of values for insertion op */ 

string: temporary-str /* used for accumulation of query conjuncts */ 



string; abdl-str 
string: join-str 
boolean: nested 
boolean: creating 
boolean: or-where 
boolean: and-where 
boolean: set-member 
boolean: common-attr 
boolean: rell 
boolean: rel2 
boolean: or-abdl-join 
boolean: or-kms-join 
boolean: delete-all 
int: target-list-length 
int: insert-list-length 



/* used for accumulation of abdl request */ 
used for accumulation of join request */ 

/* signals a nested SELECT query */ 

/* signals a DbLoad - versus a DbQuery */ 

/* signals an OR term in the WHERE clause */ 

/* signals an AND term in the WHERE clause */ 
/* signals set membership op, vice nested SEL / 
/* signals COMMON attr predicate of JOIN op * 
/* signals curr predicate assoc’d w/lst join rel '*' / 

/* signals' curr predicate assoc’d w/2nd join rel j 
/* OR in 1st join retrieve request */ 

/* OR in 2nd join retrieve request Z 
signals deletion of all records in relation / 



/ 



int: no-templates 
int: no-attributes 
int: attr-len 
char: attr-type 
char: db[] 
char: template[] 
char: attribute^ 
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% start statement 



% token /* LIST ALL TOKENS FROM "LEX", and their TYPE, HERE */ 

%% 

statement: query 

{ 

nested = FALSE 

free all tgt/insert lists and temp-str (malloc’d vars) 
return 
} 

I dml-statement 

cat End- Of- Request to end of abdl-str 

free all tgt/insert lists and temp-str (malloc’d‘*vars) 
return 
} 

I ddl-statement 

{ - -• 
return 

} 



dml-statement: insertion 
I deletion 
I update 

I 



query: query-expr 



query-expr: query-block 

{ 

cat End-Of-Request (”]”) to end of abdl-str 

} 
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query-block: select-clause FROM from-list 

.{ 

for (ea attribute name in tgt-list) 
if {! join) 

if NOT valid-attribute(db, template, attribute, attr-len) 
print ("Error - field name ’attribute-name' does not exist") 
perform yyerror() 
return 
end-if 
end-if 
else 

a join exists — check that tgt-rel(s) match at least 
one. from-list relation- ^ 

if (match neither) 

print ("Error - ’attr’ attr not in from-list relations") 
perform yyerror() 
return 
end-if 
end-else 
end- for*" 

cat "(" to abdl-str 
if (join) 

cat "(" to join-str 
end-if 
if (nested) 

fill temporary-str w/’*’s marking the length of the tgt attr 
end-if 

} 

A 

{ 

cat ")" to abdl-str 
if (! join) 

cat "(’tgt-list’)" to abdl-str 
end-if 
else 

cat "(’tgt-list’)" to abdl/join-str, as appropriate 
construct the rest of the abdl join request 
(ie, cat COMMON-str to abdl-str; cat join-str to abdl-str) 
end-else 

} 

B 
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A: empty 

{ 

cat ’’FILE = ’relation-name’” to abdl-str 

} 

I WHERE boolean 

{ 

if (! join) (or-where) 
cat to abdl-str 

* end- if 

else if (or-abdl-join) 
cat to abdl-str 

end-elseif 

elseif (or-kms-join) - ^ 

cat ")" to join-str 
"•end-elseif 
} 

B: empty 

1 GROUP BY fiefci-spec-list ' 

{ 

cat ”BY ’attribute-name’" to abdl-str 

} 

1 

select-clause: SELECT 

{ 

if (nested) 

allocate another set of tgt/insert lists, temporary-str, 
and abdl strings 
end-if 

copy "f RETRIEVE " to beginning of abdl-str 

} 

c 



C: sel-expr-list 
i MULTOP 

{ 

/* retrieval of "all" attribute values desired */ 
if (MULTOP value /= ’*’) 
print ("Error - asterisk(*) operator expected") 
perform yyerror() 
return 
end-if 

} 

) 
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sel-expr-list: sel-expr 

{ 

copy first attribute name to tgt-list 

} 

I sel-expr-list COMMA sel-expr 

{ 

copy successive attribute name(s) to tgt-list 

} 



sei-expr; expr 



insertion: INSERT INTO 

{ 

copy '*[ INSERT ('* to beginning of abdl-str * 

} 

receiver COLON insert-spec 

{ .... 

cat to abdl-str 

} 



receiver: table-name 

{ 

cat ’^<FILE, ’relation-name’ >” to abdl-str 

} 

D 
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D: empty 

{ 

/* inserting info for attribute values */ 

copy all attribute names from schema to tgt-list 
if (target-list-length < 1) 

print (’’Error - rel does not exist, or has no attr’s”) 
perform yyerror() 
return 
end- if 

} 

I LPAR field-name-list RPAR 

{ . • . . 

for (ea attribute name in tgt-list) 

if NOT valid-attribute(db, template, attribute, Jattr-len) 
print (’’Error - field name ’attribute-name’ does not exist) 
perform yyerror() 
return 
end-if 
end-for 

} : :: : 



field-name-list; field- name 

{ 

target-list-length-h+ 
copy first attribute name to tgt-list 
} 

I field-name-list COMMA field-name 
{ 

target-list-length+-h 

copy successive attribute name(s) to tgt-list 

} 



insert-spec: literal 

{ 

if (length of tgt-list < > length of insert-list) 
print (’’Error - not enough or too many values inserted”) 
perform yyerror() 
return 
end-if 

for (ea attribute in tgt-list / ea value in insert-list) 
perform type-checking of attrribute-value pairs 
cat ”,< ’attribute-name’, ’insert-value’> ” to abdl-str 
end-for 



} 
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deletion: DELETE table-name 

{ 

copy DELETE ( " to abdi-str 
copy ’table-name’ to templates 

} 

E 

{ 

if (delete-all) 

cat ’’TEMPLATE = ’table-name’” to abdl-str 
end- if 

cat to abdl-str 

} 



E; ^pty 

{ 

delete-all = TRUE 

} 

I WHERE boolean 

{ ■ 
if (or-where) 
cat to abdl-str 
end- if 
} 



update: UPDATE table-name 

{ 

copy ”[ UPDATE ( ” to beginning of abdl-str 
copy relation-name to templates 
} 

set-clause-list F 

{ 

cat ”) ’set-clause-list’” to abdl-str 

} 



F : empty 

I WHERE boolean 
{ 

if (or-where) 
cat ”)" to abdl-str 
end-if 

} 

} 
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set-clause-list: set-clause 



set-clause: SET field-name EQ expr 



{ 



if NOT validattribute(db, template, attribute, attr-len) 
print ("Error - field name ’attribute-name’ does not exist") 
perform yyerror() 
return 
end-if 
else 

copy "< ’field-name — expr’>" to abdl-str 
end-else 



ddl-statement: create- table 

j 



create-table: CREATE 

{ 

creating = TRUE 
locate db-id schema header 
} 

TABLE table-name COLON 

{ 

no- templates +H- 
create new template block 
enter ’relation-name’ in template block 
} 

field-defn-list 



field-defn-list: field-defn 

{ 

no-attributes 

} 

I field-defn-list COMMA field-defn 
{ 

no-attributes 4-f 

} 
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field-defn: field-name LPAR type- G RPAR 

{ 

create new attribute block 
enter ’attribute-name’ in attribute block 
} 



G: empty 

{ 

set key-flag to ’0’ in attribute block 

} 

I COMMA NONULL 

{ 

set key-flag to ’1’ in attribute block 

*:} 



type: CHAR LPAR INTEGER RPAR 

{ ..... 

enter attribute type and 'length in attribute block 

} 

INT LPAR INTEGER RPAR 

{ 

enter attribute type and length in attribute block 

} 

FLOAT LPAR INTEGER RPAR 

{ . 

enter attribute type and length in attribute block 

} 
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boolean: boolean-term 

{ 

if (! join) 

cat ’’-{FILE = ’relation-name’) and” to abdl-str 
cat temporary-str to abdl-str 
end-if 

} 

j boolean OR 
{ 

or-where = TRUE 
if (! join) 
abdl-str[ll] = ’(’ 

cat ”) or ((FILE = ’relation-name’) and” to abdl-str 
copy empty-str to temporary-str ^ 

end-if 
*' } 

boolean-term 

{ 

if (! join) 

cat tempbraty-str to* abdl-str 
end-if 
else 

if (current predicate assoc’d w/same rel as previous predicate) 
abdl/join-str[ll] = ’(’ 

cat ”) or ((FILE = ’rel-name’) and” to abdl/join-str (as approp) 
cat temporary-str to appropriate str (abdl/join-str) 
end-if 
else 

abdl/join-str(cis approp) [11 3] = ’(’ 

cat ”and” to appropriate str (abdl/join-str) 
cat temporary-str to appropriate str (abdl/join-str) 
end-else 

copy empty str to temporary-str 
or-where = FALSE 
end-else 

} 
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boolean- term: boolean- factor 

{ 

if (join) && (! or-where) 
determine rel that curr predicate is assoc’d with 
if (rell) && (! common-attr) 
cat ’’(FILE = ’rel-namel’) and” to abdl-str 
cat temporary-str to abdl-str 
cat ” FILE = ’rel-name2”’ to join-str 
end-if 

if (rel2) && (! common-attr) 
cat ’’(FILE = ’rel-name2’) and” to join-str 
cat temporary-str to join-str 
cat',” FILE = ’rel-namel’” to abdl-str^ 
end-if ' 

if (common-attr) 

cat ” FILE = ’rel-namel/2” to abdl/join-str’s 
end-if 
end-if 

I boolean-term* AND* 

{ 

and-where = TRUE; 
if (! join) 

cat ’’and” to temporary-str 
end-if 
} 

boolean-factor 

{ 

if (join) && (! or-where) && (! common-attr) 
if (rell) 

abdl-str[ll H- 3] = ’(' 
cat ”) and” to abdl-str 
cat temporary-str to abdl-str 
end-if 
if (rel2) 

join-str[ll -h 3] = ’(’ 
cat ”) and” to join-str 
cat temporary-str to join-str 
end-if 

copy empty-str to temporary-str 
and-where = FALSE 
end-if 

} 



boolean-factor; boolean- primary 
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boolean-primary: predicate 



predicate: expr 

{ 

if (! join) 

if NOT valid-attribute(db, template, attribute, attr-len) 
print (^’Error - field name ’attribute-name’ does not exist”) 
perform yyerror() 
return 
end-if 

if (! and- where) 
allocate new temporary-str 
end-if 

cat "(’attribute-name’ " to temporary-str 
and-where = FALSE 
end-if 
else 

save ’type’^for later comparison during type-checking, 
in ca^elihis’ rs the COMMON attribute predicate 
end-else 
} 

comparison 

{ 

if (nested) 

save attr name in case nest is actually a set membership op 
end-if 

} 

table-spec 

{ 

if (! join) 

cat ")" to temporary-str 
end-if 
else 

if (common-attr) 

save values of ’expr’, ’comparison’, ’table-spec’ 
for the COMMON expr, and type-check the two attr’s 
end-if 

if (! and-where) (! or-where) 
allocate initial temporary-str 
copy "(" to temporary-str 
end-if 
else 

cat "(" to temporary-str 
end-else 

cat "’expr’ ’comparison’ ’table-spec’)" to temporary-str 
ehd-else 
} 
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comparison: comp-op 

{ 

if (! join) 

cat ’comp-op’ to temporary-str 
if (nested) 

copy type-op-code to abdl-str.rel-op 
end- if 
end-if 

} 

5 

comp-op: EQ 
I M J 
{ 

if (nested) 

cat ’J’ to ’M’ and save 
end-if 
} 

i L 

( *' •- . •• 
nested = TRUE 

} 



J: empty 

I K 
{ 

nested = TRUE 

} 



K: ANY ! ALL 

J 

L; IN I NOT IN 

M: NE I RWEDGE GE | LWEDGE 1 LE 
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table-spec: literal 

{ 

if (! set-member) 
if (’literal[0]’ = QUOTE) 
strip quotes from literal 
change literal to ALPHANUMFIRST 
literal-const = FALSE 
end- if 

cat result, or original literal, to temporary-str 
if (nested) 

set first-ptr to top of abdl-str list 
end- if 
end-if 

else ' 

set-member = FALSE 

end-else ' 

} 

I query-expr 

{ _ , 

increment p>tr to next tgt/insert list, temp-str, and abdl-str 

} • 

I LPAR query-expr RPAR 

increment ptr to next tgt/insert list, temp-str, and abdl-str 

} 

I expr 
{ 

common-attr = TRUE 

} 
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literal: lit-tuple 

I LPAR entry-list RPAR 

{ 

set-member = TRUE 
case (set-membership-op) 

3,5.8.10 : /* <=ANY, <ANY, >=ALL, >ALL */ 

cat ’max of value set’ to temporary-str 

4, 6, 7, 9 : /* >-ANY, >ANY, <-ALL, <ALL 7 

cat ’min of value set’ to temporary-str 

1 : /* NOT IN 7 

cat first value to temporary-str 
while (other values exist) 

cat •”) and (’attr-name’ /•= ’value’” to temporary-str 
end-while ^ 

0,2 : /* IN, /=ANY 7 

cat first value to temporary-str 
if (more values exist) 
abdl-str[ll] = ’(’ 
or-where = TRUE 
end-iT 

while (other values exist) 

cat ”)) or ((TEMPLATE = ’rel-name’) and (’attr-name’” 
to temporary-str 
if ( rel-op = IN ) 
cat ” = ” to temporary-str 
end-if 
else 

cat ’7= ” to temporary-str 
end-else 

cat value to temporary-str 
end-while 
end-ca^e 



lit-tuple: entry 

' LWEDGE entry-list RWEDGE 
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entry-list: entry 

{ 

/* copy first value to insert-list */ 
insert-list-length-f-H 
if (’entry[0]’ = QUOTE) 
strip quotes from entry 
change entry to ALPHANUMFIRST 
end-if 

copy result, or original entry, to insert-list 

} 

I entry-list COMMA entry 

{ 

/* copy, successive value(s) to insert-list */ 
insert- list-length+-h 
if (’entry[0]’ = QUOTE) 
strip quotes from entry 
change entry to ALPHANUMFIRST 
end-if 

copy result, or original entry, to insert-list 

} 



entry: constant 



expr: arith-term 

I expr ADDOP arith-term 
) 



arith-term: arith-factor 

I arith-term MULT-OP arith-factor 



arith-factor: H primary 



H: empty 
ADDOP 



primary: field-spec 

set-fn LPAR field-name RPAR 
LPAR expr RPAR 
1 constant 



field-spec-list: field-spec 



144 






field-spec: field-name 

I 'table-name DOT field-name 

if (! valid-attribute(db, rel, attr, attr-len) 
print (”Error - ’rel.attr’ is invalid combination’^) 
perform yyerror() 
return 
end-if 
if (join) 

if (! or-where) || ( (or-where) (! and-where) ) 
if (table-name = rell) 
rell = TRUE 
rel2 = FALSE 

end-if ^ 

if (table-name = rel2) 
rell = FALSE 
rel2 = TRUE 
end-if 
end-if 

end-if \ \\ 

} 

7 

set-fn; AVG | MAX I MIN I SUM COUNT 



from-list: table-name 

{ 

copy first relation name to templates 
if (tgt-list = null) 

fill tgt-list with attribute names in the relation 
end-if 

} 

I from-list COIVCVIA table-name 
{ 

copy second relation name to templates 
join = TRUE 
allocate join-str 

} 



empty; : 



145 



constant: QUOTE I QUOTE 

{ 

literal-const = TRUE 
perform type-checking 
} 

I INTEGER 
{ 

perform type-checking 

} 



1: IDENTIFIER 

i value 



field-name: IDENTIFIER 



table-name; IDENTIFIER 
if (! creating) 

if NOT valid-table(db, template) 
print ("Error - relation name ’table-name’ does not exist") 
perform yyerror() 
return 
end- if 
end-if 

} 

%% 

end-proc yyparse 



proc parser () 

{ 

if (! creating) 

allocate and initialize first tgt/insert lists, temporary-str, and abdl-str 
/* if an old abdl-str exists, free it first */ 
end-if 

perform yyparse () 

reset all boolean and counter variables 

} 

end-proc parser 
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proc yyerror (s) 
char *s 

{ 

if (creating) 
set CreateDB-error-flag 

print (”Error msg - tell user which CREATE TABLE request was in error”) 
free current schema (malloc’d vars) 
end-if 
else 

free all tgt/insert lists, temp-str, and abdl-strs 
end-else 

reset all boolean and counter variables 

} . ; 

end-proc yyerror 
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APPENDIX D - THE KC PROGRAM SPECIFICATIONS 



module Kernel-Con troller() 

/* This procedure accomplishes the following: */ 

/* (1) Initialization pointers global to the Kernel Controller. */ 

/* (2) Checks si-operation to determine whether we are creating a */ 
/* database, retrieving information from the database, deleting */ 

/* information from the database, inserting information into the */ 
/* database, updating the database or if there are errors. */ 

/* (3) Depending on the appropriate operation the corresponding */ 

/* procedure is called. <% */ 

1 * 

begin module 

sql-ptr = &(cuser-rel-ptr->ui-li-type.li-sql); 
kc-ptr = &(sql-ptr->si-kc-data.kci-r-kc); 

/* Initializes pointers global to the kernel controller */ 

/* look at the si-operation to determine what action to take */ 
case si-operation 

’Create a database’: 

perform load-tables(); 
break; 

’Execute retrieve requests’: 

perform select-requests-handler(); 
break; 

’Execute retrieve common requests’: 

’Execute delete requests’: 

’Execute insert requests’: 

’Execute update requests’: 

perform rest-requests-handler(); 
break; 

’Otherwise’: /* There are errors */ 

print error message; 
break; 

end case 

end module 
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proc load-tables() 

/* This procedure accomplishes the following: */ 

/* (I) Calls dbl-template() which is a procedure */ 

/* already defined in the Test Interface. It loads */ 
the template file. */ 

/* (2) Calls dbl-dir-tbls() which is another procedure j 
/* already defined in the Test Interface. It loads */ 

/* the descriptor file. */ 

begin proc 

do initialization; /* Initialize pointer j 

% 

perform dbl-template(<ktemplate, ptr->ddli-temp.fi-fid); 
perform dbl-dir-tbls(ptr- >ddli-desc.fi-fid); 
end proc 



proc rest-requests-handler() 

/* This procedure handles common retrieve requests, insert */ 
/* requests, delete requests and update requests by calling */ 
sql-execuie(). */ 

begin proc 

perform sql-execute(); 
end proc 
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proc select-requests-handler() 



/* This procedure accomplishes the following: */ 

/* (1) Determines if we have a series of requests which */ 

/* corresponds to a nested select in SQL. */ 

/* (2) If we do have a series of requests we process the first */ 
/* request because this is the only fully formed ABDL */ 



/* request. This is accomplished by calling sql-execute(). 

/* (3) If it is a nested select, we enter a loop to process the */ 

/* remaining requests. Note that it may be necessary to */ 

/* process sub-requests. This requires entering another j 

/* loop to process these. This occurs when the number of */ 

/* responses to a request is larger than NUM-CONJ. In this */ 

/* situation a request contains at most NUM-CQNJ values. j 

(4) If it is not a nested select, then only one request */ 

requires processing. This is accomplished by casing */ ^ 

/* sql-execute. */ 

begin proc 

curr-req = &(sqKptr->si-abdl-tran-> ti-curr-req); 

/* Set curr-req equal to the first request to be processed */ 
num-reqs = &{sql-ptr->si-abdl-tran->ti-no-req); 

/* Set num-reqs equal to the number of requests to be processed */ 
kc-ptr->kcri-file-status = FIRSTTIME; 

/* Set the file status to indicate it is the first time through */ 
kc-ptr->kcri-req-status = FIRSTTIME; 

/* Set the request status to indicate it is the first time through */ 
kc-ptr->kcri-num-values-ffile = 0; 

/* Set the number of values in the file to zero */ 
strcpy (kc-ptr-> kcri-files.nri-futr.fi-fname, CURRFName); 

/* Assigns filename for the current file */ 
strcpy (kc-ptr->kcri-files.nri-curr.fi-fname, FUTRFName); 

/* Assigns filename for the future file */ 

*num-reqs = *num-reqs - 1; /* Decrement num-reqs */ 
if (*num-reqs == 0) /* Its the last subrequest */ 
sql-ptr->si-subreq-stat = LASTSUBREQ; 
else /* Its an intermediate subrequests */ 
sql-ptr->si-subreq-stat = INTERSUBREQ; 

perform sql-execute(); /* Handles the first request */ 
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while (*num-reqs > 0) /* It is a nested select 
begin while 

*nura-reqs = *num-reqs - 1; / * Decrement num-reqs */ 
perform swap-files(); Swap current and future files j 
kc-ptr->kcri-num-values-cfile = kc-ptr->kcri-num- values-ffile; 

/* Set the number of values in the current file ^ j 
kc-ptr->kcri-num- values-ffile = 0; 

/"* Reinitializes the number of values in the future file */ 
kc-ptr->kcri-file-status = FIRSTTIME; r Reintialize the status */ 
sql-ptr- >si-subreq-stat = INTERSUBREQ; /* Reinitialization the status'^/ 
curr-req->ri-ab-req = curr-req->ri-ab-req-> ari-next-req; 

Advance pointer so it points to the next request */ 
kc-ptr-> kcri-unfin-ret = curr-req->ri-ab-req->ari-req; 

Loads abdl request template into unfin- ret 
curr-req->ri-ab-req->ari-req = NULL; 

/* Sets ari-req to empty so that the completed request can */ 

/* be built into ari-req */ 

kc-ptr->kcri-req-status = FIRSTTIME; /* Reinitialize request status j 
one-conj-flag = FALSE; 

/* Sets flag^to indicate it is not a one conjunction type req j 

while ((kc-ptr->kcri-num-values-cfile > 0) && ( !one-conj-flag )) 

/* There are values left to insert into the request */ 
begin while 

perform build-request( &one-conj-flag ); 

/* Builds the next request */ 
perform sql-execute(); 

/* Handles the request just built */ 
perform free( curr-req->ri-ab-req-> ari-req ); 

/* Frees ari-req j 

curr-req->ri-ab-req->ari-req = NULL; 

Reinitializes ari-req */ 
end while 

/* Sets up for the next request j 
curr- req- >ri-ab-req-> ari-req = kc-ptr-> kcri-unfin-ret; 

/* Set ari-req equal to unfin-ret; */ 
kc-ptr->kcri-unfin-ret = NULL; 

/* Reinitailize unfin-ret */ 

. perform fclose(kc-ptr-> kcri-files.nri-curr.fi-fid): 

/* Close the current file * / 
end while 
end proc 
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proc sql-execute() 

This procedure accomplishes the following: . j 

/* (1) Sends the request to MBDS using Tl-S$TrafXJnit() */ 
/* which is defined in the Test Interface. */ 

/* (2) Calls sql-requests-left{) to ensure that all requests j 
/* have been processed. */ 

(3) Calls Tl-fmishO for post operation processing. */ 

begin proc 

perform TI-S$TrafUnit(sql-ptr->si-curr-db.cdi-dbname, 

* sql-ptr->si-abdl-tran-> ti-curr-req.ri-ab-req-> ari-req); 
/* Sends the request to MBDS */ ’ ' 

perform sql-chk-responses-left () ; * 

/* Wait until all responses have been returned */ 

perform Tl-finishO; 

/* Routine to tidy- things up after processing is completed */ 
end proc 



152 



proc sql-chk-responses-left() 

This procedure accomplishes the following: */ 



/* (1) Receives the message from MBDS by calling 

TI-RSMessage() which is defined in the Test Int. */ 
/* (2) Gets the message type by calling TI-R$Type. */ 

/* (3) If not all responses to the request have been j 

!* returned, a loop is entered. Within this loop a 
/* case statement separates the responses received by */ 
message type. * / 



1'^ (4) If the response contained no errors, then procedure */ 

/* TI-R$Req-res() is called to receive the response from */ 

/" MBDS. V 

(5) A check is then made to determine if this is the last */ 

response. If it is, then the results are returned to */ ^ 

/* the calling routine. If it was not the last response */ 

/* then the results are filed in future- results-file. */ 

/* (6) If the message contained an error then procedure */ 

/* TI-RSErrorMessage is called to get the error message */ 
and then procedure TI-ErrRes-output is called to */ 

/* output the error mesage. j 

begin proc 

num-reqs = (5i(sql-ptr->si-abdl-tran-> ti-no-req); 

/* Number of requests left, not counting the request */ 
currently being worked on. j 

response = sql-ptr->si-kfs-data.kfsi-rel.kri-response; 

/* Initailize response */ 

done = FALSE; /* Initialize flag */ 

while ( not done ) 

/* Not all responses for the current request have been received */ 
perform TI-RSMessage(); /* Receive message from MBDS */ 
msg-type = TI-R$Type(); /* Get the type of the received message */ 
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case msg-type j'^ Is the response correct or are there errors? */ 

’CH-ReqRes’: /* The response is correct */ 
done = chk-if-last-response(); 

/* Set flag if its the last response */ 

case sql-ptr->si-operation 

’Execute Retrieve Requests’: 

’Execute Retrieve Common Requests’: 
if (*num-reqs == 0) 

/* If there are no requests left, send the results to */ 

/* the formatter. */ 

KfsQ; • 
else 

/*There are requests left the in nested select to process */ 
file-future-results(); /* Save the results */ 
break; 

’Execute DeleCe Requests’: 
print ’’Delete Query Done”; 
break; 

’Execute Insert Requests’: 
print ’’Insert Query Done”; 
break; 

’Execute Update Requests’: 
print ’’Modify Query Done”; 
break; 

end case 
break; 

’Requests With Errors’: 
perform TI-RSErrorMessage{request,err-msg); 

/* Get the error message */ 
perform TI-ErrRes-output (request, err-msg); 

/* Output the error message */ 
done = TRUE; /* Set the flag */ 
break; 

end case 
end while 
end proc 
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proc build-request ( one-conj-flag ) 

/* This procedure accomplishes the following: */ 

/* (1) Builds the next ABDL request to be processed by */ 

/* calling either N-Conjunction, Not-In-Conjunction or */ 

/* One-conjunction depending on the relational operator. */ 

/* (2) Sets one-conj-flag if procedure One-Conjunction is */ 

/* called. V 

begin proc 

curr-abdl-req == &(sql-ptr->si-abdl-tran-> ti-curr-req); 

/* Gets the current ABDL request ■ */ ^ 

case curr-abdl-req->ri-ab-req->ari-rel-op 

/* Switches based upon the relational operator in the request */ 

Tn Operator’: 

perform N-Conjunction(); 
break: " * ’ 

’Not In Operator’: 

perform Not-In-Conjunction(); 
break; 

’Not Equal to Any Operator’: 
perform N-Conjunction(); 
break; 

’Less than or Equal to Any Operator’: 

perform One-Conjunction(kc-ptr->kcri-max.maxi-val.dvi-int) 

*one-conj-flag = TRUE; 

break; 

’Greater than of Equal to Any Operator’: 

perform One-Conjunction(kc-ptr->kcri-min.mini-val.dvi-int); 

"^one-conj-flag = TRUE; 

break; 

’Less than Any Operator’: ' 

perform One-Conjunction(kc-ptr->kcri-max.maxi-val.dvi-int) 

*one-conj-flag = TRUE; 

break; 
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’Greater than Any Operator’: 

perform One-Conjunction(kc-ptr->kcri-min.mini-val.dvi-int); 

*one-conj-flag = TRUE; 

break; 

’Less than or Equal to All Operator’: 

perform One-Conjunction(kc-ptr->kcri-min.mini-va].dvi-int); 

*one-conj-flag = TRUE; 

break; 

’Greater than or Equal to All Operator’: 

perform One-Conjunction(kc-ptr->kcri-max.maxi-val.dvi-int); 

*one-conj-flag = TRUE; ^ 

break; 

’Less than All Operator’: 

perfrom One-Conjunction(kc-ptr->kcri-min.mini-val.dvi-int); 
*one-conj-flag = TRUE; 
break; ... 

’Greater than All Operator’: 

perform One-Conjunction(kc-ptr->kcri-max.maxLval.dvi-int); 

*one-conj-flag = TRUE; 

break; 

end case 
end proc 
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proc .N-Conjunction() 

/* This procedure accomplishes the following: -*/ 

/* (1) Builds an N conjunction ABDL request using a template */ 

(the unfinished return) provided by KMS. */ 

j'^ (2) This is accomplished by loading in the action portion of */ 

/* the template, loading up to NUM-CONJ conjunctions into j 
/* the request, ’oring’ the conjunctions together and then */ 

/* adding the target list. */ 

/* (3) The conjunction portion is formed by copying from the */ 

/* beginning of the conjunction to first a^terik of the */ 

/* template into ari request. Then the next value from the */ 

the current file is inserted into the ari request^ */ 

followed by the remainder of the conjunction.^ If this */ 

/*-: is not the last conjunction of the request, then an or */ 

/* is inserted and the next conjunction is constructed using */ 

/* the same process. */ 

begin proc 

abdl-ptr = sql-ptr->si-abdl-tran->ti-curr-req.ri-ab-req; 

/* Set pointer to the current ABDL request */ 

if (kc-ptr->kcri-req-status == FIRSTTIME) 

Calculates values that will be used on all calls to this procedure */ 
for a given request. Thus, these values are only calculated once. */ 

begin if 

for (i 0; kc-ptr- >kcri-unfin-ret[i] != LPARAN; i+^) 

kc-ptr->kcri-beg-conj = i;/*Mark position where the conjunction begins"^/ 
action-len = kc-ptr->kcri-beg-conj;/*does not include 1st LPARAN */ 
for ( ; kc-ptr->kcri-unfm-ret[i] != ASTERIK; i++) 

kc-ptr->kcri-beg-asterik = i;/*Mark position of the first asterik*/ 
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/* Calculates the size of the template. */ 

unfm-ret-len = strlen{kc-ptr->kcri-unfinrret); 

for (i = unfin-ret-len; kc-ptr->kcri-unfin-ret[i] != ASTERIK; i--) 

kc-ptr->kcri-end-asterik = i;/'^Mark position of last asterik*/ 
for ( ; kc-ptr->kcri-unfin-ret[i| 1= LPARAN; ) 

for ( ; kc-ptr->kcri-unfin-ret[i] != RPARAN; i— ) 

kc-ptr->kcri-end-conj = i; 

/*Mark position of the end of the conjunction*/ 
target-len = unfin-ret-len - kc-ptr->kcri-end-conj -j- 1; 
conj-len = unfin-ret-len - target-len - action-len; 

/* Calculates the maximum length of the finished request. */ 

'' kc-ptr->kcri-req-len = (action-len + (NUM-CONJ. * conj-len) -r 
(NUM-CONJ * ORLen) -H target-len); 
kc-ptr-> kcri- files. nri-curr.fi-fid = 
fopen(kc-ptr->kcri-files.nri-curr.fi-fname, ’^r'^); 
kc-ptr->kcri-req-status = RESTTIME; 

end if 
else 

begin else 

/* Reset the length of the unfinished request */ 
unfm-ret-len = strlen(kc-ptr->kcri-unfm-ret); 
end else 

/* Allocates space for the finished request. */ 
abdl-ptr->ari-req = var-str-alloc(kc-ptr->kcri-req-len); 

/* load request with action portion and an { */ 
for (i = 0; i != (kc-ptr-> kcri-beg-conj H- l); i-^+) 
abdl-ptr->ari-req[i] = kc-ptr->kcri-unfm-ret[i]; 

j = i; 
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counter = 1; 

while ((counter <= NUM-CONJ) && (kc-ptr->kcri-num-values-cfile != 0)) 
/*Keep building conjunctions, filling them with values 
& ’oring’ them together*/ 

begin while 

l'^ loads template up to asterik */ 

for (i = kc-ptr->kcri-beg-conj; i != kc-ptr->kcri-beg-asterik; i4— h) 
begin for 

abdl-ptr->arl-req[jl = kc-ptr->kcri-unfin-ret[i]; 
end for 

/* loads in the next value */ ‘ ^ 

\ for (i = 0; ((abdl-ptr->ari-req[j] = 

getc(kc-ptr->kcri-files.nri-curr.fi-fid)) != ’0); i-l— h) 

j+- i-;- 

/* loads the appropriate number of ) behind the conj */ 
for (i = (kc-ptr->kcri-end- asterik -K 1); 

i != (kc-ptr->kcri-end-conj -H l); i-j— h) 
begin for 

abdl-ptr->ari-req[j] = kc-ptr->kcri-unfin-ret[i]; 
end for 

if ((counter != NUM-CONJ) IlIl (kc-ptr.->kcri-num-values-cfile != 1)) 
/* It is not the last conjunction */ 



begin if 

/* loads " or into the request to connect the conjs */ 
abdl-ptr->ari-req[j-h-r] = BLANKSPACE; 
abdl-ptr->ari-req[j-h-h] = ’o’; 
abdl-ptr->ari-req[j-h+l = ’r’; 
abdl-ptr->ari-req[j+-h] = BLANKSPACE; 
end if 
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else /* It is the last conjunction */ 
begin else 

/* loads the target list one value oer line */ 
for (i = (kc-ptr->kcri-end-conj); i != (unfin-ret-len + 1); i^-f) 
begin for 

abdl-ptr->ari-req[j] = kc-ptr-> kcri-unfm-retfij; 
end for 

/* checks if there is only one value in this request. */ 

if true then one set of parenthesis is replaced with blanks */ 
if (counter == 1) 

begin if ^ 

abdl-ptr->ari-req[kc-ptr->kcri-beg-conj] = BLANKSPACE; 
abdl-ptr->ari-req[kc-ptr->kcri-end-conj] = BLANKSPACE; 
end if 

end else 

counter-h-h; 

kc-ptr-> kcri-num- values-cfile— ; 
end while 

if (kc-ptr->kcri-num-values-cfile == 0) 

/* Set the status to signify the last subrequest */ 
sql-ptr->si-subreq-stat = LASTSUBREQ; 

end proc 



160 



proc Not-In-Conjunction() 

/* This procedure accomplishes the following: */ 

(1) Builds a one conjunction ABDL request using a template j 
/* provided by KMS. */ 

/* (2) This is accomplished by loading in the action portion of * / 

the template, loading up to NUM-CONJ conjunctions into */ 
the request, ’anding’ the conjunctions together and then */ 

/* adding the target list. */ 

(3) The conjunction portion is formed by copying from the / 

/* beginning of the conjunction to first asterik of the */ 

I"" template into ari request. Then the next value from the */ 

the current file is inserted into the ari request^ 

/* followed by the remainder of the conjunction. If this */ 

/V is not the last conjunction of the request, then an and */ 

is inserted and the next conjunction is constructed */ 

/* using the same process. */ 

begin proc 

abdl-ptr = sql-ptr->si-abdl-tran->ti-curr-req.ri-ab-req; 

/* Set pointer to the current ABDL request */ 

if (kc-ptr->kcri-req-status == FIRSTTIME) 

/* Calculates values that will be used on all calls to this for a */ 

/* given request. Thus, these values are only calculated once. */ 

begin if 

for (i = 0; kc-ptr->kcri-unfm-ret [i] != ASTERIK; i++) 

kc-ptr->kcri-beg-asterik = i;/*Mark position of first asterik"^/ 
for ( ; kc-ptr->kcri-unfin-ret[i] != LPARAN; i— ) 

kc-ptr->kcri-beg-conj = i;/*Mark position where conjunction begins"^/ 

/* Calculates the size of the template / 

unfin-ret-len = strlen(kc-ptr->kcri-unfm-ret); 

for (i = unfin-ret-len; kc-ptr->kcri-unfin-ret[ij != ASTERIK; i— ) 

kc-ptr->kcri-end-asterik = i;/*Mark position of the last asterik"^/ 
for ( ; kc-ptr->kcri-unfin-ret[i] != RPARAN; i^-^) 

kc-ptr->kcri-end-conj = i; 

/* Mark position where the conjunction ends */ 
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action-len = kc-ptr->kcri-beg-conj; 

target-len = unfin-ret-len - kc-ptr->kcri-end-conj; 

conj-len = unfin-ret-len - target-len - action-len; 

/* Calculates the maximum length of the finished request. */ 
kc-ptr->kcri-req-len = (action-len -h (NUM-CONJ * conj-Ien) -h 
(NUM-CONJ * ANDLen) + target-len); 
kc-ptr->kcri-files.nri-curr.fi-fid = 
fopen(kc-ptr->kcri-files.nri-curr.fi-fname, 
kc-ptr->kcri-req-status = RESTTIME; 
end if 
else 

begin else I 

/* Reset the length of the unfinished request */ 
unfin-ret-len = strlen(kc-ptr->kcri-unfm-ret); 
end else 

/* Allocates space for the finished request */ 
abdl-ptr->ari-req = var-str-alloc(kc-ptr->kcri-req-len); 

/* load request with action portion and an ( */ 
for (i = 0; i != (kc-ptr->kcri-beg-conj); i+-r) 
abdl-ptr->ari-req[ij = kc-ptr->kcri-unfin-ret[ij; 

j = i; 

counter = 1; 

while ((counter <= NUM-CONJ) && (kc-ptr->kcri-num-values-cfile != 0)) 
Keeps building conjunctions, filling them with values and . */ 

/* ’anding’ them together. j 

begin while 

/* loads template up to asterik */ 

for (i = kc-ptr->kcri-beg-conj; i != kc-ptr->kcri-beg-asterik; i+^n) 
begin for 

abdl-ptr->ari-req[j] = kc-ptr->kcri-unfin-ret[ij; 

j++; 

end for 
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/* loads in next value */ 

for (i = 0; ((abdl-ptr->ari-req[j] = 

getc(kc-ptr->kcri-files.nri-curr.fi-fid)) != ’0); i-f^) 

!* loads a ) behind the conjunction */ 

abdl-ptr->ari-req[j] = kc-ptr->kcri-unfin-ret[kc-ptr-> kcri-end-conjj; 

if ((counter != NUM-CONJ) &A: (kc-ptr->kcri-num-values-cfile != 1)) 
/* It is not the last conjunction * / 
begin if 

loads and into the request to connect {he conjs */ 
abdl-ptr->ari-req[j-h- 1-] = BLANKSPACE; ' 

\ abdl-ptr->ari-req[j++] = ’a’; 
abdl-ptr->ari-req[j+H-] = ’n’; 
abdl-ptr->ari-req[j-i-+] = ’d’; 
abdl-ptr->ari-req[j++] = BLANKSPACE; 
end if 

else /* It is the last conjunction */ 
begin else 

/* loads the target list including a */ 

for (i = (kc-ptr->kcri-end-conj + 1); i != (unfin-ret-len -f 1); i+-h) 
begin for 

abdl-ptr->ari-req[j] = kc-ptr->kcri-unfin-ret[i]; 
j^-h; 
end for 
end else 
counter-r+; 

kc-ptr- > kcri-num- values-cfile— ; 
end while 

if (kc-ptr->kcri-num- values-cfile == 0) 

Set the status to signify the last subrequest * / 
sql-ptr->si-subreq-stat = LASTSUBREQ; 

end proc 



163 



proc One- Conjunction (value) 



/* This procedure accomplishes the following: */ 

/* (1) Builds a one conjunction ABDL request using a template */ 

/* provided by KMS. */ 

/* (2) This is accomplished by loading in the unfinished return */ 

/* up to the first asterik, loading in the value passed to */ 

/* the procedure and then loading in the remainder of the */ 

/* of the unfinished return. */ 

begin proc ^ 

abdl-ptr = sql-ptr->si-abdl-tran-> ti-curr-req.ri-ab-req; 

/* Set pointer to the current ABDL request */ ^ 

for (i = 0; kc-ptr-> kcri-unfin-ret[i] != ASTERIK; i-j— b) 

j 

kc-ptr->kcri-beg-asterik = i; Mark postion of the first cisterik */ 

/* Calculate the-maximum length of the finished request. */ 
kc-ptr->kcri-req-len = (strlen(kc-ptr->kcri-unfin-ret) -H INTSIZE); 
for (i = kc-ptr->kcri-req-len; kc-ptr->kcri-unfin-ret[i] != ASTERIK; i— ) 

kc-ptr->kcri-end-asterik = i; Mark the position of the last asterik. */ 
kc-ptr- > kcri-files.nri-curr.fi-fid = 
fopen(kc-ptr-> kcri-files.nri-curr.fi-fname, ”r'’); 

/* Allocate space for the finished result. */ 
abdl-ptr->ari-req = var-str-alloc(kc-ptr->kcri-req-len); 

/* load request up to the first asterik */ 
for (i = 0; i != kc-ptr->kcri-beg-a.sterik; i-f-h) 
abdl-ptr- >ari-req[ij = kc-ptr-> kcri-unfin-ret[i]; 

j = i; 

/* loads in the min or max value */ 
num-to-str (value, value-str); 
for (k = 0; k != strlen(value-str); k-h+) 
begin for 

abdl-ptr- >ari-req[j] = value-str[kj; 
end for 
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/* loads the remainder of the request including the target list */ 
for (i = (kc-ptr->kcri-end-asterik ^ 1); 

i != strlen(kc-ptr-:>kcri-unfin-ret) -hi; i+-h) 
begin for 

abdl-ptr->ari-req[j] = kc-ptr->kcri-unfin-ret[i]; 
end for 

abdl-ptr->ari-req[jj = ’ 
sql-ptr->si-subreq-stat = LASTSUBREQ; 

.end proc 



proc chk-if-last-response() 

This procedure accomplishes the following: */ 

/* (l) Determines the length of the response. */ 

/* (2) Determines if this is the last response to a given request and */ 
/* returns a boolean indicating such. */ 

begin proc 

Calculates response length */ 
for (response-length = 0; 

sql-ptr-> si-kfs-data.kfsi-rel.kri-response [response-length] != EOResult; 
response-length-f-r); 

^—response-length; 

/* Checks if this is the last response */ 

if (sql-ptr->si-kfs-data.kfsi-rel.kri-response[response-length - 3] 

== CSignal) 
return(TRUE); 

else /* It is not the last response */ 
return(FALSE); 

end proc 
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proc file-future-results() 

/* This procedure accomplishes the following: */ 

/* (1) Removes the attribute names from the response. ; 

/* (2) Places the remaining attribute values into the */ 

/* future- results-file. */ 

/* (3) Keeps track of how many sub-requests there are. */ 

/* (4) Calculates and stores max and min values. j 

begin proc 

max-ptr = &(kc-ptr->kcri-max); /* Initialize pointer */ 
min-ptr = &(koptr-> kcri-min); /* Initialize point;^r */ 
f-ptr = &(kc-ptr->kcri-files); /* Initialize pointer */ 

o 

if (kc-ptr->kcri-file-status == FIRSTTIME) 
j'^ Do the following initialization */ 

begin if ^ ^ 

max-ptr->maxi-val.dvi-int = MINVAL; 
min-ptr->mini-val.dvi-int = iVlAXVAL; 
f-ptr- >nri-futr.fi-fid = fopen(f-ptr->nri-futr.fi-fname, 'V”); 
kc-ptr->kcri- file-status = RESTTIME; 
end if 

else 

f-ptr-> nri-futr.fi-fid = fopen (f-ptr- > nri-futr.fi-fname, ’^a^’); 
kc-ptr->kcri-curr-pos = 1; 

response = sql-ptr->si-kfs-data.kfsi-rel.kri-response; 
kc-ptr->kcri-res-len = strlen(response); 

/* Number of values in the returned result of the request */ 
num-values = &(kc-ptr->kcri-num-values-ffile); 
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while ( kc-ptr->kcri-curr-pos < (kc-ptr->kcri-res-len) - 2) 



begin while 

for (;response[kc-ptr->kcri-curr-posj != EMARK;kc-ptr-> kcri-curr-pos-r—) 

; /* Skip the attribute name */ 

(kc-ptr-> kcri-curr-pos) 

for (val-len = 0;response[kc-ptr-> kcri-curr-pos -r val-len] != EMARK; 
vaMen -h+) 

; /* Find out how long the attribute value is */ 

/* Allocate storage space for the value */ 
temp-str = var-str-alloc(val-len l); 
j ~ 

\ for ( ;response[kc-ptr-> kcri-curr-pos] != EMARK;J<c-ptr->kcri-curr-pos^-f ) 
begin for 

/* Load the value into the future file */ 
putc(respqnse{kc-ptr-> kcri-curr-pos], f-ptr->nri-futr.fi-fid); 

/* Load the va-lue into the temp string */ 
temp-str{j-f-hj = response[kc-ptr-> kcri-curr-pos]; 
end for 

(kc-ptr- > kcri-curr-pos) -f—h; 
putc(’0, f-ptr->nri-futr.fi-fid); 
temp-str[j] = ’ 

*num-values = "^num-values -f 1; /* Count the number of values */ 

Calculates the maximum value of those values returned so far */ 
max-ptr->maxi-val.dvi-int = 

max(max-ptr->maxi-val.dvi-int, str-to-num(temp-str)); 

Calculates the minimum value of those values returned so far */ 
min-ptr->mini-val.dvi-int = 

min(min-ptr->mini-val.dvi-int, str-to-num(temp-str)); 
free(temp-str); 
end while 

fclose(f-ptr->nri-futr.ri-fid); 
end proc 
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proc swap-files() 



/* This procedure swaps the contents of the future file with the */ 
/* contents of the current file. */ 

begin proc 

curr-fp = <k(kc-ptr->kcri-fi]es.nri-curr); 

fut-fp = &(kc-ptr->kcri-files.nri-futr); 

temp.fi-fid = curr-fp- >fi-fid; 

strcpy( temp.fi- fname, curr-fp- >fi-fname); 

curr-fp- >fi-fid = fut-fp- >fi-fid; 

strcpy (curr-fp- >fi- fname, fut-fp- >fi-fname); 

fut-fp- >fi-fid = temp.fi-fid; 

s'trcpy (fut-fp- > fi-fname, temp.fi-fname) ; 

end proc 
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APPENDIX E - THE KFS PROGRAM SPECIFICATIONS 



module kfs () 

/* This procedure accomplishes the following: 

/* (l) Calls initialize() j 

/* (2) Calls fill-table-headings() */ 

/* (3) Calls one-hscreen-results() if the width of the */ 

/* output table is less than the width of the screen */ 

/* (4) Calls more() to output the results file if the last */ 

/* response buffer has been received ^ */ 

/* (5) Calls finish() to free used memory after the las*t j 
/* < response buffer has been received */ 

begin module 

proc initialize(); /* Set up structures and variables for processing */ 
proc fill-table-headings(); /* Get headings for relational output */ 
if (table-width <— O’utputCols) /* If table size <= screen width */ 
proc one-hscreen-results(); 
else 

proc all-hscreen-results(); /* This procedure has not been written */ 
if (last response buffer) 
begin 

proc more(); /* Output relational output file to screen */ 
proc finish(); /* Close out sturctures and variables and free space j 
end if 

end module 



169 



proc initializeO 

/* This procedure accomplishes the following: */ 

/* (l) Sets kfs-r-ptr to the address of the current relational */ 
j'^ database */ 

/* (2) Sets kri-curr-pos to 1, the starting point in the response j 

/* buffer "" j 

/* (3) If this is the first time for a particular set of responses */ 

/* then an Output File is opened for write status; otherwise */ 
/* the Output File is opened for append status */ 



begin proc . 

set kfs-r-ptr to the address of the current relationaf database; 
kfs-r-ptr->kri-curr-pos = 1; /* Sets a pointer in the response array to 

the beginning of the array */ 

if (kfs-r-ptr->kri-status == FIRSTIME) /* If this is the first time 

that this procedure has been 
called for this particular 
response then */ 

begin 

open Output File for ’^write” status; 

kfs-r-ptr->kri-status = FIRSTBUF; /* Change status to indicate that 

the FIRST BUFFER is being 
handled */ 

end if 
else 

open Output File for ’^append*' status; This is not the first time 

thru this procedure so we 
need to append the results 
to the results already in the 
Output File */ 

end proc 
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proc fill-table-headings() 

/* This procedure accomplishes the following; */ 

/* (1) Fills different fields in various structures so that an */ 

/* output table similiar to one created in SQL can be made j 
/* to show results coming from MBDS */ 

begin proc 

curr-pos = kfs-r-ptr->kri-curr-pos; /* curr-pos used to hold actual 

current position in the results 
buffer so that kri-curr-pos can 
be set back to this value when we 
exit this procedure 

allocate a new table-entry-info node; ' 

read the attribute name from the response buffer; 

(fetermine the length of this name and store in new-tei-ptr-> tei-name-len; 
new-tei-ptr-> tei-val-len = proc get-size(new-tei-ptr-> tei-attr); 

/* Get the max size that this attr can possibly take on */ 
new-tei-ptr-> tei-col-len = proc max(new«tei-ptr-> tei-name-len, 

new-tei-ptr-> tei-val-len); 

/* Determine the actual column size in the output table */ 
thi-first-ent = new-tei-ptr; /* First entry for output table is equal 

to the results we just obtained */ 

thi-curr-ent = new-tei-ptr; /* The current entry is also equal to these 

results */ 

proc skipnameorval(); /* Skip over the attr value in response buffer 
until the next attr name is hit */ 
temp-attr = next attr name in response buffer; 
while (temp-attr <> thi-first-ent->attr-name) 
begin 

allocate a new table-entry-info node; /*i.e., new-tei-ptr */ 
new-tei-ptr-> tei-attr = temp-attr; 
determine the length of this name and store 
in new-tei-ptr-> tei-name-len; 

new-tei-ptr-> tei-val-len = proc get-size(new-tei-ptr->tei-attr); 

/* Get the max size that this attr can possibly take on */ 
new-tei-ptr- > tei-col-len = proc max(new-tei-ptr-> tei-name-len, 

new-tei-ptr-> tei-val-len); 

/* Determine the actual column size in the output table */ 
tbl-ptr->thi-curr-ent-> tei-next = new-tei-ptr; 
tbl-ptr-> thi-curr-ent = new-tei-ptr; 
proc skipnameorval{); ' 

temp-attr = next attr name in response buffer; 
end while 

kfs-r-ptr-> kri-curr-pos = curr-pos; /* Restore current position */ 
end proc 
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proc one-hscreen-results() 

/* This procedure outputs the results in SQL table form if this table */ 
/* can fit within the width of one screen */ 

begin proc 

if (FIRSTBUF == TRUE) 
begin 

proc load-titles(); /* Output the headings of the table */ 
kfs-r-ptr->kri-status = RESTBUFS; Change status to indicate 

that titles/headings no 
longer have to be output */ 

end if 

while (kfs-r-ptr->kri-curr-pos < kfs-r-ptr->kri-res-l$n) 

^begin 

tbl-ptr = kfs-r-ptr->kri-form-data.thi-first-ent; 

/* Get the first table entry so that you can work from here 
while (tbl-ptr <> NULL) 
begin 

proc skipnameorval();« 

column-difference = tbl-ptr->tei-col-len - proc get-val-lfen(); 

/* column-difference indicates the difference between the 
actual column length and the length of the attr value to 
be output. We need this to determine how many spaces are 
needed to keep our results left-justified */ 
print the attr value; 

print a series of blank spaces equal to the column-difference; 
print a 

tbl-ptr = tbl-ptr-> tei-next; /* Get the next table entry j 
end while 

print a carriage return; 
end while 
close Output File; 
end proc 
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proc load-titles() 



/* This procedure loads the heading of a SQL results table into the */ 
output file */ 

begin proc 

tbl-ptr = kfs-r-ptr->kri-form-data.thi-first-ent; 

/* Get the first table entry so that you can work from here */ 
while (tbl-ptr <> NULL) 
begin 

column- difference = tbl-ptr- >tei-col-len - tbl-ptr->tei-name-len; 

/* column-difference indicates the difference between the 
actual column length and the length of the attr value to 
be output. We need this to determine how many spaces are 
needed to keep our results left-justified */ . 
print the attr name; 

print a series of blank spaces equal to the column-difference; 
print a ”1 

tbl-ptr = tbl-j)tr-> tei-next; 
end while " “ ’ 

print a carriage return: 

print a series of equal to the width of the table; 
end proc 



proc get-size(x) 

/* This procedure obtains the maximum size that a particular attribute j 
value may take on */ 

char x; 

begin proc 

traverse the table entry list until you find the attr name equal to x; 
retum(the length of this attr name); 
end proc 
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proc more() 

/* This procedure is just like the more facility offered in Unix */ 

It is not as sophisticated, however. */ 

begin proc 

open kfs-r-ptr->kri-o-file.fi-fname for ”read’’ status; 
get a char from opened file; 

• while (NOT EOF) 
begin 

counter = 0; /* counter is used to keep track of how many lines 
have been printed on the screen */ 
while ((counter <= screen-heigth) AND (NOT COF)) 
begin 

print the char; 
if (c == carriage return) 
counter = counter -h 1; 
get a char from opened file; 
end while 

• • I • 

if (counter > screen-heigth) 
begin 

print the word ”~more— 

determine if user wants to quit or advance 1 to screen-heigth lines 
in the opened file; 

end if 
end while 
end proc 

proc skipnameorval() 

This procedure skips over either an attribute name or attribute value */ 
depending where kri-curr-pos is currently located. This is necessary */ 

/* because results are coming back as: ATTR-NAME ATTR-VALUE. In some */ 
situations we want just the NAME and in others we want just the VALUE */ 

begin proc 

update kri-curr-pos to skip over the the attr name or value 
that it is currently positioned at; 

end proc 
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proc finish() 



/* This procedure frees any structure space that may have been created */ 
/* during the creation of the ouput table */ 

begin proc 

tbl-ptr = current relational database; 

tbl-ent-ptr = tbl-ptr- > thi-first-ent;/* Set tbl-ent-ptr to the first 

table entry /* 

while (tbl-ent-ptr <> NULL) 
begin 

tbl-ptr-> thi-first-ent — tbl-ent-ptr-> tei-next; 

/* Get the next table entry */ . ^ 

tbl-ent-ptr-> tei-next = NULL; ^ 

free(tabl-ent-ptr); 
tbl-ent-ptr = tbl-ptr- > thi-first-ent; 
end while 
end proc 
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APPiNDIX F - JHE SQL USERS' MANUAL 



A. Overview 

The SQL language interface allows the user to 
input transactions from either a file or the terminal. A 
transaction can take the form of either creates of a new 
database or queries against an existing database. The 
SQL language interface is menu— driven. When the 



transactions are read from either a file or the terminal 
they are stared in the interface. If the transactions 
are creates they are executed automatically by the system- 
If the transactions are queries the user will be 
prompted by another menu to selectively pick an individual 
query to be processed- The menus provide an easy and 
efficient way to allow the user to see and select the 
methods in which to perform the mapping functions- Each 
menu is. tied to its predecessor so that by exiting each 
menu the user is moved back up the menu "tree”. This 
allows the user to perform multiple tasks in one session. 

B. USING THE SYSTEM 

There are two operations the user can perform on 
the database schemas- The user can either create a new 
database or process queries against an existing database- 
The first menu displayed prompts the user for which 
fu.nction to perform- This menu, hereafter named MENUl , 
looks like the following: 
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Enter type of operation desired 
<1) — load a new database 
(p) - process old database 
(x) — return to the operating system 

ACTION > 

Upon selecting the desired operation, the user will 
be prompted to enter the name of the database to be used- 
For the case that the load operation was selected, the 
database name provided cannot^ be presently used. 
LiJJewise, for a process old operation the database name 

provided must be in existence- In either case, if an 
error occurs the user will be told to rekey a different 
name. The session continues once a valid name has been 
entered . 

For either type of operation selected from MENUl , the 
second menu is the same and asks for the mode of input. 
This input may come from a data file or interact! vely 
from the terminal. The generic menu, called MENU2, looks 
like the following: 

Enter mode of input desired 

(f) - read in a group of transactions from a file 

(t) - read in transactions from the terminal 

(x) — return to the previous menu 

ACTION > 

If the user wishes to read transactions from a file he 
will be prompted to provide the name of the file that 
contains those tr ansacti ons- If the user wishes to enter 
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transactions directly from the terminal a message wi 1 1 be 
displayed reminding him of the correct format and 
special characters that must be used. Since the 
transaction list stores both creates and queries, two 
different access methods must be employed to send the two 
types of transactions to the KMS. Therefore, our 
discussion branches to handle the two processes the user 
will encounter. 5 

1 . PEQcessing Creates ; ' 

When the user has specified the filename of creates 

(if the input is from a file) or typed in a set of creates 
(if the input is from the terminal), further user 
intervention is not required. It does not make sense to 
process only a single create out of a set of creates that 
produce a new database since they all must be processed at 
once and in a specific order- Therefore, the 
transaction list of creates is automatically e>?ecuted by 
the system- Since all the creates must be sent at once to 
form a new database, control should not return to MENU2 
where further transactions can be input. Instead, 
control returns to MENUl where the user can pick a new 
operation or nev-^ database. 

2 . 

In this case, after the user has specified his 
mode of input, he will conduct an interactive session 
with the system- First, all queries will be listed to the 
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screen . 



As the queries are listed from the transaction 
list, a number is assigned to each query in ascending 
order starting with the number one. The number is 
printed on the screen beside the first line of each query- 
Next, an access menu, called MENU3, is displayed which 
looks like the following: 

Pick the number or letter of the action desired 

(num) - execute one of the ft^receding queries 

(d) - redisplay the list of queries 

(x) — return to the previous menu 

ACTION > 

Since* the displayed queries might exceed the 

vertical height of the screen, only a screen full of 
queries will be displayed at one time- If the desired 

query is not on the current page, the user can hit the 

RETURN key to display the next page of queries- If the user 

only wishes to print a certain number of lines, then after 
the first page is displayed the user can enter a number and 
only that many lines of queries will be displayed. If the 
user is only looking for certain queries, once he has 
found them he does not have to page through the entire 
transaction list- By hitting the q key, control will 

break from listing queries and NENU3 will be displayed. 
Under normal conditions when the end of the transaction list 
has been viewed, NENU3 will appear. 
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Since queries are independent items, the order in 
which they are processed does not matter. The user has 
the choice of executing however many queries he desires. 
A loop causes the query listing and MENU3 to be 
redisplayed after any query has been executed so that 
further choices may made. Unlike processing creates, 
control returns to MENU2 because the user may have more than 
one file of queries against a particular database or he 
may wish to input some extra queries / directly from the 
terminal. Once he has finished processing on this 
particular database., he can exit back to MENUl ‘ to either 
change operations or exit to the operating system. 

C. DATA FORMAT 

When reading transactions from a file or the terminal, 
there must be some way of distinguishing when one 
transaction ends and the next begins. Transactions are 
allowed to span multiple lines as evidenced by a typical 
nested SQL select. Since the system is reading the input 
line by line, an end-of -transact i on flag is needed. In 
our system this flag is the character. Likewise, the 
system needs to knov^ when the end of the input stream has 
been reached. In our system the end— of-file flag is 
represented by the character. The following i s an 
example of an input stream with the necessary flags that 
must be included when multiple transactions are entered: 
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TRANSACTION #1 

TRANSACTION #2 
@ 



TRANSACTION #n 
$ 

D. RESULTS •» 

*' When the results of the executed .-transacti ons are sent 

back to the user's screen, they will be displayed exactly 
the same way queries are displayed <See section B-2) . 

The following consolidates the user's options: 

H 1- 

! KEY ; FUNCTION ! 

H 1 f- 

1 return ! displays next screenful of output ! 

i I I 

I I I 

! (number) 1 displays only (number) lines of output i 

It I 

! q 1 stops output, MENUl is then redisplayed 1 

+ (- 
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